_current` view per table keeps the newest version of each row. For the `services` snapshot table, it keeps only the latest run.
Point Power BI or Tableau at the `_current` views. The tables and their columns are listed under **Table Contract** on the Data Share page.
## Related
Run logs, pausing and the table contract.
The BigQuery destination.
The S3 destination.
How the private key is stored.
# Workday Strategic Sourcing
Source: https://docs.coverbase.com/integrations/guides/workday-strategic-sourcing
Procurement-driven intake: Workday Strategic Sourcing pushes suppliers into Coverbase, which enriches, tiers, and assesses them automatically.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Coverbase integrates with **Workday Strategic Sourcing (WSS)** in production today. The sourcing event is the trigger: when procurement advances a supplier in WSS, the supplier record flows into Coverbase, which enriches the vendor with AI, ingests the supplier's uploaded documents, maps procurement's classification onto your risk tiers, and, when a review is due, launches the assessment automatically. Security review keeps pace with procurement without anyone re-keying data.
```mermaid theme={null}
flowchart LR
subgraph wss["Workday Strategic Sourcing"]
supplier["Supplier record"]
docs["Supplier documents"]
end
subgraph cb["Coverbase"]
imp["Import API"]
enrich["AI vendor enrichment"]
tier["Tier & risk-level mapping"]
assess["Assessment (when due)"]
end
supplier -->|push on sourcing event| imp
imp --> enrich --> tier
docs -->|fetched by URL| assess
tier --> assess
```
## What flows
WSS pushes a supplier record into an org-scoped Coverbase import endpoint. From one push, Coverbase:
1. **Upserts the vendor and service**, keyed on WSS identifiers, so replays update rather than duplicate.
2. **Enriches the vendor with AI.** Company profile, description, and risk-relevant context are filled automatically rather than left blank for an analyst.
3. **Fetches the supplier's documents** from the URLs in the WSS record (security questionnaires, certifications, contracts) and stores them on the vendor with their WSS provenance recorded.
4. **Maps procurement's classification to your risk model.** WSS tier, data-classification, and volume answers translate to Coverbase custom fields and the vendor's risk level on your scale.
5. **Creates the assessment when one is due**, seeded with the fetched documents as supporting evidence, so the AI analysis starts from what procurement already collected. Pushes for suppliers not yet due for review update the record without launching redundant work.
6. **Activates the vendor and service** so they appear in your live portfolio immediately.
## Trigger model
```mermaid theme={null}
sequenceDiagram
participant WSS as Workday Strategic Sourcing
participant CB as Coverbase
WSS->>CB: Push supplier record (sourcing event)
CB->>CB: Upsert vendor + service, AI enrichment
CB->>WSS: Fetch supplier documents by URL
CB->>CB: Map tier + data classification to risk level
alt review is due
CB->>CB: Create assessment seeded with documents
else not yet due
CB->>CB: Update records only
end
```
## Reliability
* **Idempotent on WSS identifiers.** Re-pushed suppliers refresh the existing vendor and service; assessment creation is gated on review cadence, so procurement re-syncs never spawn duplicate assessments.
* **Validated before writes.** Malformed records are rejected with a field-level message and leave nothing behind.
* **Document provenance preserved.** Every document fetched from WSS is stored with its source recorded, so evidence in an assessment is always traceable to the procurement event that supplied it.
* **Graceful partial data.** A supplier record missing optional fields (documents, classification answers) still lands; the mapping fills what it has and leaves the rest to enrichment or the analyst.
## Authentication and provisioning
WSS pushes authenticate with an org-scoped Coverbase service-account API key, provisioned during onboarding and manageable through the [API keys](/api-reference/api-keys) surface. Document fetches use the URLs carried in the WSS record.
## In production
Runs procurement-driven vendor security review: every supplier advancing through Workday Strategic Sourcing lands in Coverbase already enriched, classified onto the company's vendor tiers, and, when due, under assessment with the supplier's own uploaded evidence attached. Incoming vendors and services activate immediately, so the security team's portfolio always matches procurement's reality.
## Onboarding checklist
1. A Coverbase service-account API key for the WSS push (provisioned during onboarding).
2. The WSS webhook or workflow step that pushes the supplier record at your chosen sourcing stage.
3. Your tier and data-classification vocabulary in WSS, mapped once to Coverbase risk levels and custom fields.
4. Assessment cadence rules: which tiers get assessed, and how often.
# What to expect during onboarding
Source: https://docs.coverbase.com/integrations/onboarding
How onboarding works, what Coverbase builds with you, what you configure yourself, and what security teams typically request.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Workflows in Coverbase are built in a no-code designer in the **Workflows** section of the dashboard, by your admins, at any time. Onboarding is a head start rather than a dependency: Coverbase sits with you and builds the first workflow set from your existing process documentation and integration targets, and hands it over as ordinary editable definitions.
There is no read-only stage and no configuration-only tier. Every trigger, condition, action and webhook Coverbase builds with you is one your admins can edit, clone, disable or replace, from the dashboard or the API, without involving Coverbase support. The same is true of control sets, questionnaires, statuses, approval options, risk domains, scales, custom fields and terminology. See [Configuring your data model](/user-guides/data-model-configuration).
## What you configure, and what we build with you
| You, self-serve | Coverbase, with you |
| - | - |
| Workflows: triggers, conditions, actions, review gates and approval routing | The first workflow set, built from your process documentation during onboarding |
| Control sets, questionnaires, clause sets, report templates | Advice on which library frameworks to fork for your regulatory profile |
| Custom fields, statuses, approval options, scales, risk domains, tags, terminology | - |
| Users, roles, user groups, out-of-office routing, SSO | - |
| API keys, webhooks, and self-serve integrations such as DocuSign, Slack, Jira, ServiceNow and ProcessUnity | - |
| - | Deep bidirectional connectors to a GRC, ERP or CLM system of record, where field mapping to your instance is genuine integration work |
## What security teams typically request
For integration architecture review, security teams typically request the following, all of which we provide on engagement:
Published in the [event catalog](/integrations/webhooks#event-catalog), and offered in the dashboard as the trigger picker in any workflow and the **Events** picker under **Configuration → Webhooks**.
One example payload for every subscribed event type. **Send test** on the **Webhooks** page previews the sample payload for any event type and can copy it as cURL.
The retry behavior, signature scheme, and verification approach described in the [Webhooks](/integrations/webhooks) reference.
The list of API endpoints used by the integration, scoped to the API key permissions required.
## Reference architectures
Several platforms have full deep-dive guides covering architecture diagrams, data mapping, trigger model, and what onboarding needs from your team:
* [ProcessUnity](/integrations/guides/processunity): bidirectional, in production
* [ServiceNow VRM](/integrations/guides/servicenow): in production
* [OneTrust](/integrations/guides/onetrust): in production
* [Workday Strategic Sourcing](/integrations/guides/workday-strategic-sourcing): in production
* [Aravo](/integrations/guides/aravo): triage-layer architecture
Pre-built reference architectures are available on request for:
* Ariba
* [Jira](/integrations/guides/jira)
* The major CLM platforms (Icertis, Ironclad, DocuSign CLM, Conga)
## What an integration delivery looks like
Platform integrations are stood up **sandbox-first**: the connector is configured and verified end to end against your platform's sandbox or sub-production tenant, including live read-back of what persisted, before production credentials are exchanged. A typical delivery runs:
1. **Credentials and scoping.** You provision a scoped integration identity (OAuth client, integration user, or API token) for the sandbox tenant; secrets are held in Coverbase's secrets manager, never in configuration.
2. **Mapping workshop.** Your field vocabulary (assessment types, ratings, statuses, custom attributes) is mapped once onto Coverbase's model, with tenant-specific identifiers recorded in configuration.
3. **Sandbox verification.** Full lifecycle runs against the sandbox, verified by reading the results back from your platform.
4. **Production cutover.** Production credentials swap in; the mapping carries over unchanged.
## Next steps
If you'd like to walk through how this maps to your specific environment, including which inbound integrations to prioritize, which webhook events to wire up first, and how onboarding sequences against your existing GRC and procurement stack, contact your Coverbase representative.
We can also share customer reference architectures from organizations with similar tooling profiles.
# Integration Workflows
Source: https://docs.coverbase.com/integrations/overview
How Coverbase integrates with the systems your organization already runs, end to end.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
This page describes how Coverbase integrates with the systems your organization already runs and how those integrations behave end to end. It's intended for security, integration, and procurement teams evaluating Coverbase as part of a broader third-party risk and vendor lifecycle stack.
The integration model is built around three layers: inbound API calls that bring data and commands into Coverbase, a workflow engine that orchestrates the work, and outbound webhooks that notify your downstream systems as work progresses.
## Architecture
External systems push data and commands into Coverbase. Procurement platforms create vendors, intake forms submit questionnaires, CMDBs sync service catalogs, and GRC tools start assessments. Each is a standard authenticated API call.
Once data lands, the workflow engine takes over. Triggers fire on object events, scheduled runs, or external invocation. Conditions branch the flow on risk score, tier, data class, jurisdiction, or contract value. Actions execute the work: create an assessment, send a portal to the vendor, raise review gates in parallel, and wait for their outcomes.
As workflows progress, Coverbase fires webhooks to endpoints you control. Webhooks carry the event type and the affected object, so ServiceNow, Jira, Slack, Ariba, Icertis, or your data warehouse can react in real time.
```mermaid theme={null}
flowchart LR
subgraph inbound["Your systems (inbound)"]
proc["Procurement (Ariba, Workday Strategic Sourcing)"]
grc_in["GRC platforms (ProcessUnity, Aravo)"]
cmdb["CMDB / intake forms"]
end
subgraph coverbase["Coverbase"]
api["Inbound API"]
engine["Workflow engine"]
objects["Vendors · Services · Assessments · Findings"]
out["Connectors & webhooks"]
end
subgraph outbound["Your systems (outbound)"]
sor["Systems of record (ProcessUnity, ServiceNow VRM, OneTrust)"]
itsm["Jira · Slack · Icertis"]
dw["Data warehouse"]
end
proc --> api
grc_in --> api
cmdb --> api
api --> engine --> objects --> out
out --> sor
out --> itsm
out --> dw
```
For the platforms Coverbase integrates with natively, including bidirectional GRC deployments running in production today, see the [platform-specific guides](/integrations/guides/processunity), and [integration patterns](/integrations/patterns) for the four shapes those integrations compose.
**Orchestration is yours to configure and to change.** Workflows are built in a no-code designer in the **Workflows** section of the dashboard: pick a trigger, add conditions, add actions, activate. Coverbase will build the first set with you during onboarding, and they are handed over as ordinary editable definitions rather than as locked configuration. After that, both the definitions and every running instance are reachable through the dashboard and the API, so you can interrupt, modify, or replace any step at any time. See [Configuring your data model](/user-guides/data-model-configuration).
## Public API surface
The public resource API covers these operations:
| Resource | Operations |
| - | - |
| Vendor | Create, list, get, update, read and refresh the fact sheet (`POST`/`GET`/`PATCH /v1/vendors`) |
| Service | Create + update under a vendor (`POST`/`PATCH /v1/vendors/{id}/services`) |
| User | Provision (create-or-get), list / look up by email, get, update role / deprovision (`POST`/`GET`/`PATCH /v1/users`) |
| Document | Upload, list, get, download, update, delete (`/v1/documents`) |
| Assessment | Create, get, archive (`POST /v1/assessments`, `GET`/`DELETE /v1/assessments/{id}`) |
| Finding | List, create, get, status-sync (`/v1/findings`) |
| Obligation | List, create, get, status-sync (`/v1/obligations`) |
| Radar | List and create events, list and triage alerts, list detectors and sources (`/v1/radar`) |
| Reassessment | Create, curate vendors, confirm, dismiss, run (`/v1/reassessments`) |
| Workflow | Run, schedule, list runs, get run with steps (`POST /v1/workflows/{name}/run`, `POST /v1/workflows/{name}/schedule`, `GET /v1/workflows/runs`) |
| Custom field | Discover definitions, read and write values (`/v1/custom-fields`) |
| Webhook | Create, list, update, delete, test, delivery history (`/v1/webhooks`) |
Bulk vendor/assessment loading is also available through the separate [Import API](/import-api). Control sets, statuses, tags, and scale levels are referenced **by ID** in these requests/responses; configure them in the dashboard.
The public API uses plural route names (`/v1/vendors`, `/v1/assessments`). Internal dashboard routes use singular nouns and are not part of the supported public surface.
## Where to go next
The four shapes every integration composes: inbound push, outbound sync, webhooks, file-based import.
How the ProcessUnity, ServiceNow, OneTrust, Workday Strategic Sourcing, and Aravo integrations work, with architecture diagrams.
Triggers, conditions, and actions. How orchestration logic is composed.
Three patterns for starting work in Coverbase from outside the UI.
Register endpoints, subscribe to event types, verify signatures, handle retries.
Full lifecycle walkthroughs for onboarding, parallel review, monitoring, and offboarding.
Gate outcomes, parallel domain-scoped SME reviews, multi-approver logic, and rework loops.
# Integration patterns
Source: https://docs.coverbase.com/integrations/patterns
The four integration shapes every Coverbase integration composes: inbound push, outbound sync, webhooks with workflows, and file-based import.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Every Coverbase integration, including the shipped [platform guides](/integrations/guides/processunity), composes the same four shapes. This page names them so your integration or platform team can map your systems onto them before the first architecture call.
```mermaid theme={null}
flowchart LR
subgraph external_in["Your systems"]
grc["GRC / TPRM platform"]
proc["Procurement / sourcing"]
files["Spreadsheets & exports"]
end
subgraph coverbase["Coverbase"]
import["Import API"]
engine["Workflow engine"]
store["Vendors · Services · Assessments · Findings"]
export["Export API & connectors"]
hooks["Webhooks"]
end
subgraph external_out["Your systems"]
sor["System of record"]
itsm["ITSM / ticketing"]
warehouse["Data warehouse"]
end
grc -->|push| import
proc -->|push| import
files -->|upload| import
import --> engine --> store
store --> export --> sor
store --> hooks --> itsm
hooks --> warehouse
```
## 1. Inbound push
Your system of record stays in charge and pushes into Coverbase: a procurement platform creates the vendor, a GRC platform starts the assessment, an intake form submits a questionnaire. Each push is a standard authenticated API call to an org-scoped endpoint.
What makes inbound pushes production-safe:
* **External IDs are the contract.** Every pushed record carries your system's identifier. Coverbase stores it and keys all matching on it, so a replayed delivery updates the existing record instead of duplicating it.
* **Validation before writes.** Required identifiers are checked before anything is persisted; a rejected payload leaves nothing behind. Rejections return `422` (malformed or missing fields) or `409` (the payload conflicts with existing records) with a message naming the offending field.
* **Replays are safe.** Redelivering the same payload refreshes the record from the latest data and never dispatches duplicate work: no second assessment run, no duplicate intake session, no re-imported attachments.
Used by the [ProcessUnity](/integrations/guides/processunity), [Workday Strategic Sourcing](/integrations/guides/workday-strategic-sourcing), and [Aravo](/integrations/guides/aravo) integrations, and by the generic [Import API](/import-api).
## 2. Outbound sync
Coverbase pushes results back into the system your auditors and downstream teams already look at: assessment outcomes, scores, review decisions, findings, and documents land as native records in the external platform.
What makes outbound syncs production-safe:
* **Native records, not exports.** Results are written to the platform's own object model (a ProcessUnity assessment record, a ServiceNow Vendor Risk assessment, a OneTrust risk), so downstream reporting works unchanged.
* **Idempotent upserts.** Every outbound record is keyed on an external ID. Re-running a sync updates in place; it never duplicates.
* **Best-effort by design.** An external platform outage never blocks your analysts: syncs are logged and retried, and a failed push never fails the assessment or the user's action that triggered it.
* **Platform limits handled proactively.** Field length caps, rate limits, and write-contention retries are handled inside the connector, not left to your team to discover.
Used by the [ProcessUnity](/integrations/guides/processunity), [ServiceNow](/integrations/guides/servicenow), and [OneTrust](/integrations/guides/onetrust) integrations.
## 3. Webhooks and workflows
For systems that want to *react* rather than hold a mirrored copy, Coverbase fires [webhooks](/integrations/webhooks) as objects change and the [workflow engine](/integrations/workflow-engine) orchestrates multi-step processes. External systems can also [trigger workflows](/integrations/triggering-workflows) directly.
This is the lightest-weight shape: no field mapping, no connector. An endpoint you control receives signed events and decides what to do.
## 4. File-based import
For platforms without a usable API, or for one-time migrations, Coverbase imports structured files (Excel, CSV) through per-format import specifications that parse your questionnaire or vendor export into Coverbase's control and question model. The same external-ID matching applies, so a file import and a later API integration reconcile onto the same records.
Used for bulk vendor loads, historical assessment migration, and questionnaire imports during onboarding. See the [Import API](/import-api).
## Composing the shapes
Real deployments combine shapes. A typical GRC coexistence deployment uses **inbound push** (the GRC platform starts assessments), **outbound sync** (results land back on the GRC record), and **webhooks** (ticketing and chat notifications along the way). See [end-to-end workflows](/integrations/end-to-end-workflows) for the full picture, and the [platform guides](/integrations/guides/processunity) for how each shipped integration composes them.
# Triggering workflows from external systems
Source: https://docs.coverbase.com/integrations/triggering-workflows
Three patterns for starting work in Coverbase from outside the UI.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The most common integration question is whether an external system can start work in Coverbase without anyone touching the UI. Yes. There are three patterns.
## Pattern 1: Create the object, let triggers handle the rest
Most workflows are bound to object events. The cleanest integration is to bring the object into Coverbase and let the workflow engine react.
Create the vendor with [`POST /v1/vendors`](/api-reference/vendors) (and its services with `POST /v1/vendors/{id}/services`), or load many at once through the [Import API](/import-api). Once a vendor is created, a workflow bound to the `Vendor.Created` trigger runs: conditions inspect the imported attributes, classify the vendor, and the workflow can launch an assessment, send a portal, and notify the internal owner with no UI interaction.
Use this pattern when the work maps naturally onto an object lifecycle. Use Pattern 2 or 3 when you need to start work explicitly against an existing object.
## Pattern 2: Explicitly start an assessment
When an external system needs to start an assessment on an existing vendor, for example a GRC tool beginning annual reassessment of a known vendor, it can call the assessments endpoint directly.
```bash cURL theme={null}
curl -X POST "https://api.coverbase.app/v1/assessments" \
-H "Authorization: Bearer ak_live_xxx" \
-H "Content-Type: application/json" \
-d '{
"vendor_id": "cbvndr_e448ba62882143f3ba0c140bb2e30162",
"control_set_ids": ["cbctst_9f4a1c0d7b2e4e9f8c1d2b3a4e5f6071"],
"service_ids": ["cbsvc_3c2b1a098f7e6d5c4b3a2918374655ab"],
"trigger_workflow": "annual-reassessment-flow"
}'
```
The `trigger_workflow` parameter is optional. If specified, that named workflow is started alongside the assessment (a `404 workflow_not_found` is returned if no workflow with that name exists for the org). See the [Assessments API](/api-reference/assessments) for the full request and response schema.
## Pattern 3: Invoke a named workflow directly
For cases that don't map cleanly to a single object event, for example sending the standard data privacy questionnaire to forty vendors and aggregating responses into a quarterly report, external systems can invoke a workflow by name and pass it parameters.
```bash cURL theme={null}
curl -X POST "https://api.coverbase.app/v1/workflows/quarterly-privacy-sweep/run" \
-H "Authorization: Bearer ak_live_xxx" \
-H "Content-Type: application/json" \
-d '{
"input": {
"vendor_filter": { "tags": ["processes_pii"] },
"due_date": "2026-06-30"
}
}'
```
The workflow must be enabled and have a **Direct** entrypoint (the trigger reads **Running the workflow**), whose input is the `input` you send. A disabled workflow returns `409 workflow_disabled`. The response includes a `workflow_run_id` you can poll with `GET /v1/workflows/runs/{id}`, and `GET /v1/workflows/runs` lists runs. To run it later instead of now, call `POST /v1/workflows/{name}/schedule` with a `scheduled_for` Unix timestamp.
```json theme={null}
{
"workflow_run_id": "cbwr_a8f2c19e3d4b5e6f7a8b9c0d1e2f3a4b",
"workflow_name": "quarterly-privacy-sweep",
"status": "started",
"started_at": 1746576000,
"input": { "vendor_filter": { "tags": ["processes_pii"] }, "due_date": "2026-06-30" }
}
```
See the [Workflows API](/api-reference/workflows) for the full schema.
## Idempotency
`POST /v1/assessments`, `POST /v1/workflows/{name}/run` and `POST /v1/workflows/{name}/schedule` accept an `Idempotency-Key` header, as do `POST /v1/vendors`, `POST /v1/users` and `POST /v1/documents`. If the same key is replayed within 24 hours for that endpoint, the original response body is returned and no new run is started. Full behavior is documented in [API conventions → Idempotency](/conventions#idempotency).
```bash cURL theme={null}
curl -X POST "https://api.coverbase.app/v1/workflows/onboard-vendor/run" \
-H "Authorization: Bearer ak_live_xxx" \
-H "Idempotency-Key: ariba-req-7821" \
-H "Content-Type: application/json" \
-d '{ "input": {} }'
```
Use an identifier from the source system (a procurement request ID, a ticket number) as the idempotency key. That way retries from the source system are naturally deduplicated without extra bookkeeping on your side.
# Webhook delivery history
Source: https://docs.coverbase.com/integrations/webhook-deliveries
Inspect every webhook delivery attempt: status, response, and payload.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Coverbase records **every** webhook delivery attempt as an audit row. Whether the delivery came from a [domain-event fan-out](/integrations/webhooks#when-deliveries-happen), a workflow [`send_webhook` action](/integrations/workflow-engine#actions), or a manual [test](/api-reference/webhooks#test-a-webhook), there is one history record per attempt, including deliveries that were blocked by the [URL restrictions](/integrations/webhooks#url-restrictions).
Use the history to debug failing receivers, confirm a delivery happened, and monitor delivery health over time. The aggregate health of a subscription (`last_delivery_status`, `delivery_success_rate`, `delivery_count`) is also surfaced on the [webhook object](/api-reference/webhooks#response-fields).
## In the dashboard
Under **Configuration → Webhooks**, click a webhook's **Delivery history** button, or its **Health** value. The dialog lists each attempt with its **Event**, **Status**, **Response** (HTTP status and round-trip time) and **Attempted** time, newest first, with **View payload** to expand what was sent. The **Status** filter narrows the page you are looking at, and **Previous** and **Next** page through the rest.
## List delivery attempts
`GET /v1/webhooks/{webhook_id}/deliveries`
Returns the delivery attempts for one webhook, **newest first**, paginated. Org-scoped to the API key.
### Path parameters
The webhook subscription ID (`cbwh_...`).
### Query parameters
Page size. Clamped to the range `1`-`100` (values outside the range are clamped, not rejected).
Number of records to skip. Negative values are clamped to `0`.
### Example request
```bash cURL theme={null}
curl "https://api.coverbase.app/v1/webhooks/cbwh_d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9/deliveries?limit=50&offset=0" \
-H "Authorization: Bearer ak_live_xxx"
```
```python Python theme={null}
import os
import requests
API_KEY = os.environ["COVERBASE_API_KEY"]
BASE_URL = "https://api.coverbase.app"
webhook_id = "cbwh_d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9"
resp = requests.get(
f"{BASE_URL}/v1/webhooks/{webhook_id}/deliveries",
headers={"Authorization": f"Bearer {API_KEY}"},
params={"limit": 50, "offset": 0},
timeout=30,
)
resp.raise_for_status()
print(resp.json())
```
### Example response
```json theme={null}
{
"data": [
{
"id": "cbwhd_9c7b4a2e8b3c1a4d9e7f2c5b6a8d1e3f",
"webhook_id": "cbwh_d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9",
"event_id": "cbevt_8b3c1a4d9e7f2c5b6a8d1e3f9c7b4a2e",
"event_type": "Vendor.Created",
"status": "delivered",
"response_status": 200,
"response_time_ms": 142,
"error": null,
"payload": { "event_type": "Vendor.Created", "vendor_id": "cbvndr_e448ba62882143f3ba0c140bb2e30162" },
"attempted_at": 1747400001,
"created_at": 1747400001
}
],
"total": 1,
"limit": 50,
"offset": 0
}
```
### Response fields
The page of delivery attempts, newest first. Each item:
Delivery attempt ID (`cbwhd_...`).
The subscription this attempt belongs to (`cbwh_...`).
The shared event ID (`cbevt_...`) sent in the envelope and the `X-Coverbase-Event-Id` header.
The event type the delivery was labeled with.
One of `delivered`, `timeout`, `error`.
The receiver's HTTP status code, or `null` if no response was received (timeout, connection error or blocked URL).
Round-trip time in milliseconds, or `null` if no response was received.
Error detail when `status` is `timeout` or `error` (for example, a blocked-URL message); otherwise `null`.
The `data` object that was delivered for this attempt.
Unix timestamp (seconds) when the attempt was made.
Unix timestamp (seconds) when the audit row was written.
Total recorded attempts for this webhook, ignoring `limit`/`offset`. Page until `offset + len(data) >= total`.
The effective page size after clamping.
The effective offset after clamping.
### Delivery status values
| Status | Meaning |
| - | - |
| `delivered` | The receiver answered with a `2xx` status. `response_status` and `response_time_ms` are populated. |
| `timeout` | The request exceeded the 10-second per-attempt timeout. |
| `error` | The receiver answered with a non-`2xx` status (`response_status` is populated), a connection error occurred, or the URL was blocked by the [delivery-time SSRF re-check](/integrations/webhooks#url-restrictions). `error` carries detail. |
Every attempt is its own row. A delivery that timed out, lost its connection, or got a `408`, `429` or `5xx` answer is retried with the same `event_id`, up to six attempts in all, so the newest row for an `event_id` is where that delivery stands. Other non-`2xx` answers are recorded as `error` and not retried.
### Error responses
| Status | Body | When |
| - | - | - |
| 404 | `{"detail": {"code": "webhook_not_found", "message": "Webhook not found."}}` | The `webhook_id` does not exist or is not in the API key's org. |
### Pagination example
```bash Next page theme={null}
curl "https://api.coverbase.app/v1/webhooks/cbwh_d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9/deliveries?limit=50&offset=50" \
-H "Authorization: Bearer ak_live_xxx"
```
See [API conventions → Timestamps](/conventions#timestamps) for the epoch-seconds convention used by `attempted_at` and `created_at`.
# Webhooks
Source: https://docs.coverbase.com/integrations/webhooks
Delivery format, fan-out, signature verification, retries, and the event catalog.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Webhooks are the outbound half of an integration. This page documents how events are delivered, how to verify signatures, retry behavior, and the event catalog. To register, list, update, delete, test, or inspect the delivery history of a subscription, see the [Webhooks API](/api-reference/webhooks). For the audit trail of every attempt, see [Webhook delivery history](/integrations/webhook-deliveries).
Admins can do the same from the dashboard under **Configuration → Webhooks** (see the [Webhooks guide](/user-guides/webhooks)). Members see the list and the delivery history but cannot add, change, test or delete a webhook, in the dashboard or through the API. **Add webhook** takes an **Endpoint URL**, a **Signing secret** of at least 16 characters (shown only once), the **Events** to subscribe to, an optional **Description**, and an **Enabled** switch. Each row has **Send test**, **Delivery history**, **Edit** and **Delete** buttons, and the **Health** column shows the last delivery's status and the share of recorded attempts that got a `2xx` response.
## When deliveries happen
When a subscribed event occurs, Coverbase POSTs a JSON envelope to **every active webhook subscribed to that event type**. Deliveries originate from three sources, and all of them are recorded in [delivery history](/integrations/webhook-deliveries):
* **Domain-event fan-out**: a domain event (for example, a vendor is created) fans out to every subscription for that event type.
* **Workflow `send_webhook` action**: a workflow automation explicitly delivers its triggering event, either to the webhooks the action names or to every subscription for the event type. See [Workflow engine → Actions](/integrations/workflow-engine#actions).
* **Manual test**: the [test endpoint](/api-reference/webhooks#test-a-webhook), or **Send test** on the **Webhooks** page, sends a one-off delivery to a single subscription.
For one source event, the **same `event_id` is shared across all webhooks** in the fan-out. Receivers can use it to dedupe a fan-out and to correlate a multi-subscription delivery. A workflow `send_webhook` action generates its own `event_id` each time it runs, so an event delivered by both the fan-out and a workflow action arrives with two different IDs.
A webhook with no events selected receives nothing from the fan-out. Use that for an endpoint that should only receive what a workflow's `send_webhook` action addresses to it.
## Delivery format
A delivery is an HTTP `POST` with a JSON body in this exact envelope:
```json theme={null}
{
"event_id": "cbevt_8b3c1a4d9e7f2c5b6a8d1e3f9c7b4a2e",
"event_type": "Vendor.Created",
"occurred_at": 1747400000,
"data": { "event_type": "Vendor.Created", "vendor_id": "cbvndr_e448ba62882143f3ba0c140bb2e30162" }
}
```
| Field | Type | Notes |
| - | - | - |
| `event_id` | string | Shared delivery/event identifier (`cbevt_...`). The same value for every webhook in one fan-out. |
| `event_type` | string | The event type string (see the [event catalog](#event-catalog)). |
| `occurred_at` | integer | Unix timestamp in **seconds**, generated at send time. |
| `data` | object | Event-specific payload. For real events these are the catalog fields for that event type (and `data` echoes `event_type`). For a manual test, `data` is your custom `payload` (default `{"test": true}`). |
The envelope is exactly these four keys; there is no top-level `workflow_run_id` or any other field.
### Request headers
| Header | Value |
| - | - |
| `Content-Type` | `application/json` |
| `Coverbase-Signature` | Lowercase hex HMAC-SHA256 of the raw request body, keyed by your webhook `secret`. |
| `Coverbase-Timestamp` | Same value as `occurred_at`, in Unix seconds. |
| `X-Coverbase-Event-Id` | Same value as `event_id`. |
| `X-Coverbase-Event-Type` | Same value as `event_type`. |
## Signature verification
The signature is `HMAC-SHA256(secret, raw_request_body)` rendered as a lowercase hex string, sent in the `Coverbase-Signature` header. The key is the `secret` you registered with the subscription. Verify it against the **raw bytes** of the request body, before parsing JSON, with a constant-time comparison.
To reject replayed deliveries, compare `Coverbase-Timestamp` with your own clock and drop anything outside a window you choose (five minutes is typical). The same value is inside the signed body as `occurred_at`, so an attacker cannot change the header without the body no longer matching it.
```python Python theme={null}
import hashlib
import hmac
def verify(raw_body: bytes, signature_header: str, secret: str) -> bool:
expected = hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
return hmac.compare_digest(expected, signature_header)
# Flask example
from flask import Flask, request, abort
app = Flask(__name__)
WEBHOOK_SECRET = "whsec_a1b2c3d4e5f6a7b8c9d0e1f2" # the secret you registered
@app.post("/coverbase")
def receive():
raw = request.get_data() # raw bytes, do not re-serialize
sig = request.headers.get("Coverbase-Signature", "")
if not verify(raw, sig, WEBHOOK_SECRET):
abort(401)
event = request.get_json()
# dedupe on request.headers["X-Coverbase-Event-Id"] before handling
return "", 200
```
```javascript Node.js theme={null}
const crypto = require("crypto");
function verify(rawBody, signatureHeader, secret) {
const expected = crypto
.createHmac("sha256", secret)
.update(rawBody)
.digest("hex");
const a = Buffer.from(expected);
const b = Buffer.from(signatureHeader);
return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// Express example (use express.raw so rawBody is the unparsed buffer)
app.post(
"/coverbase",
express.raw({ type: "application/json" }),
(req, res) => {
const sig = req.header("Coverbase-Signature") || "";
if (!verify(req.body, sig, process.env.WEBHOOK_SECRET)) {
return res.status(401).end();
}
const event = JSON.parse(req.body.toString("utf8"));
// dedupe on req.header("X-Coverbase-Event-Id") before handling
res.status(200).end();
},
);
```
## Delivery & retries
| Property | Value |
| - | - |
| HTTP method | `POST` |
| Connection timeout | 10 seconds per attempt |
| Retries | Up to 5 retries (6 attempts) after a timeout, a connection error, or a `408`, `429` or `5xx` response, waiting about 4 s, 16 s, 64 s, 4 min and 4 min between attempts. Any other non-`2xx` response, a blocked URL and a test event are not retried. Every attempt is recorded in [delivery history](/integrations/webhook-deliveries) |
| Ordering | Not guaranteed; deliveries are unordered |
| Duplicates | Possible: delivery is at-least-once. A retry after a timeout, or a worker that fails partway through a delivery, can send an event your receiver already processed. Every attempt carries the same `event_id` |
| Endpoint requirement | Public HTTPS endpoint (see [URL restrictions](#url-restrictions)) |
`event_id` is fixed when the event is raised and stays the same on every attempt. `occurred_at` and the `Coverbase-Timestamp` header are set again for each attempt, so a retry passes a receiver's replay window. Make your receiver **idempotent**: dedupe on `X-Coverbase-Event-Id` and process the same event id at most once. Respond with a `2xx` within 10 seconds. Retries cover a short outage, about 10 minutes from the first attempt. After a longer one, use [delivery history](/integrations/webhook-deliveries) to see which events never reached you and read the affected records back through the API.
### Source IP
Coverbase does **not** publish a fixed egress IP range for outbound webhook deliveries. Authenticate the sender by **HMAC signature verification** (see [Signature verification](#signature-verification)), not by source IP. The compute fleet is autoscaled and the public IPs that originate deliveries change frequently.
If you operate behind a network perimeter that requires a static allow-list, route deliveries through a customer-controlled HTTPS proxy with a stable egress IP and forward to the real receiver after re-verifying the signature.
## Delivery history retention
Every delivery attempt is recorded in [delivery history](/integrations/webhook-deliveries) for **90 days**. Older rows are deleted by a daily background job; the API still serves the window inside retention via `GET /v1/webhooks/{id}/deliveries`. Capture deliveries you need beyond that window from your receiver side at delivery time.
## URL restrictions
Webhook URLs must be **public HTTPS endpoints**. A URL is rejected at create/update time (`400 invalid_url`) if it is not HTTPS, carries credentials, uses a non-standard port, or resolves to a private, loopback, link-local, or metadata address (for example, `169.254.169.254`).
The same check is **re-applied with DNS resolution at delivery time**, and the delivery connects only to an address that check approved, with TLS still verifying the endpoint's own hostname. A hostname repointed to an internal address after registration, or one that answers the check and the connection differently (DNS rebinding), is still blocked. A delivery blocked this way is recorded with status `error` in [delivery history](/integrations/webhook-deliveries).
## Event catalog
These are the **only** values valid in a subscription's `events` array and the only event types emitted. The `events` field is strictly validated against this set; see the [behavior change](#strict-event-type-validation) below. Use the exact, case-sensitive strings. The same list is what the **Events** picker on the **Webhooks** page offers.
| `event_type` | `data` fields |
| - | - |
| `Assessment.Created`, `Assessment.Updated`, `Assessment.Deleted` | `assessment_id`; `.Updated` adds `field_diffs` |
| `Assessment.ManualHandoffRequested` | `assessment_id`, `work_queue_item_id` |
| `Commitment.Created`, `Commitment.Updated`, `Commitment.Deleted` | `commitment_id`; `.Updated` adds `field_diffs` |
| `Contract.Created`, `Contract.Updated`, `Contract.Deleted`, `Contract.Expired` | `contract_id`; `.Updated` adds `field_diffs` |
| `DarkWebExposure.Created`, `DarkWebExposure.Updated`, `DarkWebExposure.Deleted` | `dark_web_exposure_id`; `.Created` and `.Updated` add the [dark web exposure payload](/api-reference/webhooks#dark-web-exposure-payload); `.Updated` adds `field_diffs` |
| `Engagement.Created`, `Engagement.Updated` | `engagement_id`; `.Updated` adds `field_diffs` |
| `Finding.Created`, `Finding.Updated`, `Finding.Deleted` | `finding_id`; `.Updated` adds `field_diffs` |
| `IntakeSession.Created`, `IntakeSession.Submitted`, `IntakeSession.Updated`, `IntakeSession.Deleted` | `intake_session_id`; `.Updated` adds `field_diffs` |
| `Obligation.Created`, `Obligation.Updated`, `Obligation.Deleted` | `obligation_id`; `.Updated` adds `field_diffs` |
| `OrgIntake.Disabled` | `removed_questionnaire_id` |
| `OrgIntake.QuestionnaireRemoved` | `questionnaire_id`, `intake_disabled` (bool) |
| `Procurement.Created`, `Procurement.Updated`, `Procurement.Deleted` | `procurement_id`; `.Updated` adds `field_diffs` |
| `QuestionnaireResponse.Created`, `QuestionnaireResponse.Updated` | `questionnaire_response_id`; `.Updated` adds `field_diffs` |
| `RadarCase.Created`, `RadarCase.Updated`, `RadarCase.Deleted` | `radar_case_id`; `.Updated` adds `field_diffs` |
| `RadarDetectorResult.Created`, `RadarDetectorResult.Updated`, `RadarDetectorResult.Deleted` | `radar_detector_result_id`; `.Updated` adds `field_diffs` |
| `RadarEvent.Created`, `RadarEvent.Updated`, `RadarEvent.Deleted` | `radar_event_id`; `.Updated` adds `field_diffs` |
| `RadarSignal.Created`, `RadarSignal.Updated`, `RadarSignal.Deleted` | `signal_id`; `.Updated` adds `field_diffs` |
| `Reassessment.Created`, `Reassessment.Updated`, `Reassessment.Deleted` | `reassessment_id`; `.Updated` adds `field_diffs` |
| `Review.Created`, `Review.Updated`, `Review.Deleted` | `review_id`; `.Updated` adds `field_diffs` |
| `RiskRegisterEntry.Created`, `RiskRegisterEntry.Updated`, `RiskRegisterEntry.Deleted` | `risk_id`; `.Updated` adds `field_diffs` |
| `ScreeningMatch.Created`, `ScreeningMatch.Updated`, `ScreeningMatch.Deleted` | `screening_match_id`; `.Updated` adds `field_diffs` |
| `Service.Created`, `Service.Updated`, `Service.Deleted` | `service_id`; `.Updated` adds `field_diffs` |
| `MonitoringRecord.Created`, `MonitoringRecord.Updated`, `MonitoringRecord.Deleted` | `monitoring_record_id`; `.Updated` adds `field_diffs` |
| `MonitoringRecord.ScopingDue` | `monitoring_record_id`, `vendor_id`, `verdict`, `closes_at_planned` (nullable) |
| `MonitoringRecordEntry.Created`, `MonitoringRecordEntry.Updated`, `MonitoringRecordEntry.Deleted` | `monitoring_record_entry_id`; `.Updated` adds `field_diffs` |
| `ServiceNowRecord.Created`, `ServiceNowRecord.Updated`, `ServiceNowRecord.Deleted` | `servicenow_record_link_id`; `.Updated` adds `field_diffs` |
| `ServiceNowSync.Completed` | `assessment_id`, `servicenow_table`, `created_record_count` |
| `Sla.Created`, `Sla.Updated`, `Sla.Deleted` | `sla_id`; `.Updated` adds `field_diffs` |
| `SupplierDiversityRecord.Updated` | `supplier_diversity_record_id`, plus the [supplier profile fields](#supplier-profile-events) |
| `SupplierLegalEntityAssignment.Assigned`, `SupplierLegalEntityAssignment.Rejected` | `supplier_legal_entity_assignment_id`, `entity_code` (nullable), plus the [supplier profile fields](#supplier-profile-events) |
| `SupplierSite.Created`, `SupplierSite.Updated`, `SupplierSite.Deleted` | `supplier_site_id`, plus the [supplier profile fields](#supplier-profile-events) |
| `SupplierTaxRegistration.Updated` | `supplier_tax_registration_id`, plus the [supplier profile fields](#supplier-profile-events) |
| `SupplierUpdateRequest.Submitted` | `supplier_update_request_id`, plus the [supplier profile fields](#supplier-profile-events) |
| `Vendor.Created`, `Vendor.Updated`, `Vendor.Deleted` | `vendor_id`; `.Updated` adds `field_diffs` |
| `VendorBankAccount.Created`, `VendorBankAccount.Updated`, `VendorBankAccount.Retired` | `vendor_bank_account_id`, plus the [supplier profile fields](#supplier-profile-events) |
| `VendorContact.Updated` | The [supplier profile fields](#supplier-profile-events) |
| `VendorDocument.Created`, `VendorDocument.Updated`, `VendorDocument.Deleted` | `vendor_document_id`; `.Updated` adds `field_diffs` |
| `WorkflowRun.Created` | `workflow_run_id`, `input` |
| `WorkflowRun.Updated`, `WorkflowRun.Deleted`, `WorkflowRun.Completed`, `WorkflowRun.Failed` | `workflow_run_id`; `.Updated` adds `field_diffs` |
| `WorkQueueItem.Created`, `WorkQueueItem.Completed`, `WorkQueueItem.Updated`, `WorkQueueItem.Deleted` | `work_queue_item_id`; `.Updated` adds `field_diffs` |
`*.Updated` events carry a `field_diffs` object mapping each changed field to its `{ "old_value", "new_value" }`, so a status change arrives as `Vendor.Updated` (or `Assessment.Updated`, `Review.Updated`, and so on) with the status field in `field_diffs`. A soft-archive (`is_archived` → `true`) surfaces as `*.Deleted`, not `*.Updated`.
A **radar alert** is a `RadarDetectorResult`: subscribe to `RadarDetectorResult.Created` to be notified of new alerts and `RadarDetectorResult.Updated` (whose `field_diffs` will include `is_dismissed`) for triage activity. A **signal** is a `RadarSignal`. See the [Radar](/api-reference/radar) and [Reassessments](/api-reference/reassessments) APIs.
### Supplier profile events
The `VendorBankAccount`, `VendorContact`, `SupplierSite`, `SupplierTaxRegistration`, `SupplierDiversityRecord`, `SupplierUpdateRequest` and `SupplierLegalEntityAssignment` events describe changes to a supplier's profile. Besides their own ID, each carries:
| Field | Notes |
| - | - |
| `change_event_id` | The profile change this event reports. Every webhook that receives the change gets the same value, so use it as your idempotency key. Nullable. |
| `vendor_id` | The supplier the change belongs to. Nullable. |
| `entity_id` | The ID of the record that changed, such as the bank account or site. Nullable. |
| `sensitivity` | `normal`, or `sensitive` for a fraud-relevant change. Bank account changes are always `sensitive`. |
| `actor_type` | Where the change came from: `supplier_portal`, `internal_user`, `api` or `system`. |
| `diff`, `snapshot` | What changed, and the saved record. Account and tax numbers appear only as their last four characters. |
A `sensitive` change fires its event only after a reviewer approves it, not when it is requested.
`SupplierUpdateRequest.Submitted` and `VendorContact.Updated` can be subscribed to, but nothing sends them yet. What a supplier changes in answer to an update request arrives as the record events above.
All IDs are opaque prefixed strings (for example, `cbvndr_...`, `cbqsrw_...`); see [API conventions → IDs](/conventions#ids). Every event's `data` also echoes its own `event_type`.
`webhook.test` is a valid value only for the [test endpoint's](/api-reference/webhooks#test-a-webhook) `event_type` field. It is **not** a subscribable event type; it will be rejected if used in a subscription's `events` array.
### Strict event-type validation
**Breaking change.** `events` is now strictly validated against the catalog above. Previously any free-form string was accepted. A `POST /v1/webhooks` or `PATCH /v1/webhooks/{id}` whose `events` contains a value not in the catalog now fails with `422 invalid_event_types`. Integrations that registered non-canonical strings (for example, lowercase `vendor.created`) must switch to the exact catalog value (for example, `Vendor.Created`).
# Workflow engine
Source: https://docs.coverbase.com/integrations/workflow-engine
How triggers, conditions, and actions compose into orchestration logic.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
A workflow is a sequence of triggers, conditions, and actions that runs against a primary object.
## Triggers
A trigger is the event that starts a workflow. Triggers fall into three groups.
A primary object is created, updated, or transitions state. Examples include a new vendor being created, an assessment moving to completion, a contract's term running out (`Contract.Expired`), or a finding being raised. Every trigger in the picker is an event in the [event catalog](/integrations/webhooks#event-catalog).
A workflow run is scheduled for a specific time. On a workflow's page, the **Run workflow** button offers **Schedule for later...**, and a **Run workflow** action inside another workflow can start its target now or at a later time. Pending runs are listed under **Scheduled** on the workflow's **History** tab, where each can be canceled. There is no recurring (cron-style) trigger: for a periodic review, use reassessment rules, which set each vendor's next assessment date from its risk level.
An external system explicitly invokes a workflow through the API. This is the integration path most relevant to procurement and GRC tooling.
See [Triggering workflows from external systems](/integrations/triggering-workflows) for the three patterns.
## Conditions
Conditions branch the flow. They evaluate fields on the primary object or its related objects.
The condition picker offers:
* IRQ score within a threshold range
* Vendor status, tier or tags
* Assessment status, assignee, recommendation, plan, risk type, inherent risk level or document collection mode
* Procurement status, reviewers and review status, and contract value
* An answer to a questionnaire question
* Which fields changed on the triggering record
* Whether work queue items are complete
* Whether the triggering record was opened by this workflow, so a chain only advances on the records it created
* Any built-in or [custom field](/api-reference/custom-fields) on the triggering record or a related record, through the same filter paths the dashboard uses. Attributes such as data classification, hosting model or jurisdiction are usually matched here.
The conditions on an automation are combined with **Match all** or **Match any**.
### Gate conditions
Four conditions exist specifically to express approval logic.
| Condition | What it evaluates | Typical use |
| - | - | - |
| **Contract value** | Total value of the contracts on a procurement against a threshold, with `greater than` and `less than or equal` operators | Delegation-of-authority routing: above the limit picks up the extra approver. Amounts are summed in the contracts' own currency and never converted; when they span two currencies the total counts as over the threshold, so the extra approver is always added |
| **Work queue item complete** | Whether the review work raised by this workflow run is finished, scoped to `self`, the vendor, or the whole run, with a **require all** toggle | Unanimous gates (`require all` on) and first-past-the-post gates (off). Vary the set of reviews you raise per tier to express a quorum |
| **Assessment recommendation** | The approval option selected on the assessment, matched against a set you choose | Route `Approve with policy exception` down a different path from `Approve` |
| **Reviewer present** | Whether a given reviewer already holds a review on the record | Avoid raising a duplicate gate on a re-triggered run |
See [Reviews, approvals and gates](/user-guides/reviews-and-approvals) for how these compose into all-of, any-of, threshold-based and sequential approval patterns.
## Actions
Actions execute work. The action picker groups them by the record they act on:
### Review gates and approvals
The **raise a review gate** action is how approval logic is expressed.
* **Scope.** A review attaches to an assessment, a contract or a procurement. Adding a risk domain makes it domain-scoped, and there is exactly one review per `(assessment, risk domain)` pair, so a domain cannot be gated twice by accident.
* **Parallel by default.** Raise several in one branch and they run at the same time, each with its own assignee, status, notes and outcome. Nothing serializes them.
* **Routing.** The assignee can be an individual or a user group. A group resolves through its own strategy at assignment time: every eligible member for an assign-to-all group, or the next person in the rotation for a round robin, skipping anyone inside an out-of-office window. Both the group and the resolved individual are stored. See [Assignment, delegation and out of office](/user-guides/assignment-and-delegation).
* **Work lands somewhere.** Each raised review mints a work queue item and notifies its assignee, so the gate appears on a person's Overview page rather than only on the record.
* **Idempotent on re-trigger.** A workflow legitimately revisits the same component many times across a reject, rework and resubmit cycle, so gate actions are keyed per run and can upsert onto an existing review instead of stacking duplicates.
### `send_webhook` action
The **Send webhook** action delivers the workflow's triggering event to [webhooks](/integrations/webhooks).
* By default the event type is the workflow's triggering event; an optional **event type override** changes the type the delivery is labeled with and, when no webhooks are named, which subscriptions are matched.
* An optional **`webhook_ids`** list names the exact webhooks to deliver to. Naming a webhook is the subscription decision: it receives the delivery whatever events it subscribes to. Omit it to fan out to every active subscription for the event type.
* A disabled or archived webhook receives nothing either way.
* One shared `event_id` is generated per action invocation, so a receiver can dedupe a multi-webhook fan-out, using the same idempotency model as the [domain-event fan-out](/integrations/webhooks#when-deliveries-happen).
Every delivery from this action is recorded in [delivery history](/integrations/webhook-deliveries). If there is no active webhook to deliver to, the step is skipped.
To start a workflow from outside the dashboard, run it by name through the API. See [Triggering workflows from external systems](/integrations/triggering-workflows).
# Replacing the assessment export
Source: https://docs.coverbase.com/mcp/assessment-exports
Map every column of the Consolidated Assessment Report export to the MCP call that returns it, with sample input, sample output, and prompts for building a GRC dashboard on top.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Teams building an internal GRC dashboard often start from the **Consolidated Assessment Report** export, then move to the MCP server so the data refreshes without anyone clicking **Export**. This page maps that spreadsheet column by column, so you can port a mapping instead of probing calls to find out what exists.
You do not need this page to ask questions about an assessment. Ask in plain language and the assistant picks the route. This is for when you are writing an integration and need to know which call returns which column.
## Column mapping
| Export column | MCP call |
| - | - |
| Assessment Name, Status, Assignee, Assessment Score | `query_assessments(kind="detail")`, and every `kind="search"` row |
| Assessment Outcome | `detail`, `summary`, `details_legacy`, and every `search` row |
| Residual Risk Score, Residual Risk Level | `detail`, `summary`, `details_legacy`, and every `search` row |
| Summary | `query_assessments(kind="summary")`. `detail` carries a preview |
| Notices | `summary` |
| Date Created, Initiated By, Run Counter | `detail` |
| Products, Services | `detail` |
| Policy Control Sets Count | `detail`, which also names the sets |
| Parsed Questionnaire Count, Parsed Policy Count | `detail`, as one **Parsed controls** line |
| Supporting Documents Count | `detail`, which also lists the documents |
| Inherent Risk Score, Inherent Risk Level | `detail`, under the vendor section |
| SLA stage timings, targets, and breaches | `detail` |
| Custom field columns | Any read that returns the assessment. See [custom fields](#custom-field-columns) |
| Errors | Not exposed. See [what is not exposed](#what-is-not-exposed) |
Every count column returns a number even when it is zero, because the export writes a number in every row. An omitted field would be indistinguishable from a count of none.
## The summary report
`kind="detail"` carries the opening 500 characters of the AI summary as a preview, then says so and names the call that returns the rest. `kind="summary"` returns the whole report.
### Input
```json theme={null}
{
"tool": "query_assessments",
"arguments": {
"kind": "summary",
"assessment_id": "cbqsrw_hub01"
}
}
```
### Output
```markdown theme={null}
# Assessment Summary: 2026 HubSpot, Inc. initial
**ID:** `cbqsrw_hub01` | https://dashboard.coverbase.app/assessments/cbqsrw_hub01
**Status:** Complete
**Outcome:** Conditionally Approve
**Recommendation status:** conditionally_approve
**Residual risk:** Moderate - score 38.24
**Assessment score:** 56.6%
**Assessment level:** Medium
**Inherent risk:** Level 3 - score 61.00
## Summary
## Decision Summary
Conditionally approve HubSpot for marketing automation.
## Key Business Risks
- Customer PII (names, emails, phone numbers) is processed in a multi-tenant CRM shared with other HubSpot customers, with logical separation only.
- No customer-managed encryption keys are offered on the current contract tier, so key rotation and revocation stay with the vendor.
## Required Conditions
1. Enforce SSO for all admin accounts by 2026-12-01.
2. Annual SOC 2 Type II on file.
## Follow-Ups
| Item | Owner | Due |
|---|---|---|
| SSO enforcement | IT | 2026-12-01 |
## Vendor Remediation Message
Please confirm SSO enforcement and share the SOC 2.
## Recommendation
Approve subject to MFA rollout across admin accounts.
## Notices
- SOC 2 expires in 30 days
```
The sections between `## Summary` and `## Recommendation` are whatever your workspace's summary prompt produces. The headings above are an example, not a fixed schema.
A summary whose underlying data was corrected after it was written is flagged as needing regeneration, so you do not publish prose that no longer matches the evaluations it describes.
### Paging a long report
Reports longer than one response can carry are truncated with a notice that names the next call:
```text theme={null}
_[Truncated: showing characters 0-20,000 of 26,400. Retrieve the rest with
query_assessments(kind="summary", assessment_id="cbqsrw_hub01", summary_offset=20000).]_
```
Pass `full_text=true` to raise the cap instead of paging.
## Mapping a whole portfolio
Do not call `kind="detail"` once per assessment. The outcome and the residual risk are on every `search` row, so a few hundred assessments map in one call per page.
### Input
```json theme={null}
{
"tool": "query_assessments",
"arguments": { "kind": "search", "limit": 50 }
}
```
### Output
```text theme={null}
Found 1 assessment(s):
- **2026 HubSpot, Inc. initial** (id: `cbqsrw_hub01`, status: Complete,
outcome: Conditionally Approve, vendor: cbvndr_hub score: 56.6%,
residual risk: Moderate - score 38.24)
```
Call `kind="summary"` only for the assessments whose narrative you need.
## Custom field columns
Custom field values come back with no extra parameter. They appear as a `## Custom Fields` section on `kind="detail"` and as an indented `_Custom:_ name=value` line under each `kind="search"` row.
Fields with no value set are omitted, so an assessment where the field was never filled in renders nothing at all. If a value is missing that you expect to be there, check the assessment in the app first: an empty field and an unreachable field look the same in the response.
`query_platform(kind="custom_fields", target_type="assessment")` lists the definitions, not the values. Use it to discover which fields exist, then read the values from the assessment itself.
## What is not exposed
**Errors** is the one export column with no MCP equivalent. It holds raw processing error payloads that can incidentally contain personal data, so it is not returned. Everything else in the export is mapped above.
## Scoring settings change what you get
Two settings under **Configuration → Scoring** change every read, matching which columns the export itself drops:
* **Residual risk tracking off**: residual risk is omitted everywhere, level and score alike.
* **Numerical scores off**: raw inherent and residual risk numbers are omitted and the named levels stay. The assessment score percent is unaffected.
If residual risk is missing from a response and you expect it, check that setting before opening a ticket.
## Prompts for this workflow
> We're replacing the Consolidated Assessment Report export with this connector. For assessment cbqsrw\_hub01, give me every field that export has: outcome, residual risk score and level, the full summary, and the counts.
The assistant reads `kind="detail"` for the decision and scope fields, then `kind="summary"` for the narrative, and tells you which columns have no equivalent rather than silently omitting them.
> Give me the complete written summary for the HubSpot assessment, not the preview. I need the decision summary, the required conditions, and the vendor remediation message.
Resolves the name to an assessment, then calls `kind="summary"`. If the report is long, it pages through and gives you the whole thing.
> List every completed assessment from this quarter with its outcome, residual risk level, and residual risk score, as a table I can load into a dashboard.
One `kind="search"` call per page carries all three fields, so this does not fan out into one call per assessment.
> Which assessments were conditionally approved, and what conditions did we attach to each?
The outcome is on the search rows, so the assistant filters there, then reads `kind="summary"` for the required conditions on only the matching assessments.
> I exported the Consolidated Assessment Report yesterday. Read the same assessments through the connector and tell me where the two disagree.
Useful as a one-off during migration. Expect residual risk to be absent if your workspace has residual risk tracking off, and expect Errors to have no equivalent.
> The ServiceNow ticket field isn't coming back for cbqsrw\_hub01. Is it set on that assessment?
Custom field values are returned automatically when set, so an absent value usually means an empty field rather than a missing route.
Every kind on every read dispatcher, and the parameters each one takes.
# Connecting clients
Source: https://docs.coverbase.com/mcp/connecting
Connect Claude Code, Claude.ai, Claude Desktop, Cursor, VS Code, Microsoft Copilot Studio, and other MCP clients to the Coverbase MCP server.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The exact connection flow depends on which client you're using. The general pattern is the same: point the client at the Coverbase MCP endpoint, complete the OAuth flow in your browser, and the tools become available in your session.
## Server endpoint
```text theme={null}
https://mcp.coverbase.app/mcp
```
The server speaks MCP over **Streamable HTTP**. On first connection your client opens a browser window so you can sign in to Coverbase and authorize access. Your permissions in Coverbase determine what the connected assistant can see and do.
## Choosing an authentication method
The server accepts two kinds of credential, and which one you want depends on whether a person is present at setup.
| | **OAuth 2.0** | **API key** |
| - | - | - |
| Setup | Browser sign-in on first connect | Paste a key into your client config |
| Best for | Desktop and IDE clients you use yourself | Headless pipelines, CI, containers |
| Identity | The signed-in user | Whoever the key was minted to act as |
| Access | Read/write, or narrower if the client asks | Read/write or read-only, fixed when the key is generated |
OAuth (PKCE, no client secret) is the default and the right choice for interactive clients. The rest of this page assumes it.
If a browser step is impossible, generate a long-lived key instead and send it as a bearer token. **This is the part that is easy to miss: a client configured with only a URL and no `Authorization` header will be answered with a `401` and pushed into the OAuth flow**, which is exactly what an API key exists to avoid.
In Coverbase, go to **Configuration → MCP Server** and generate a key under **API key**. It starts with `cb_mcp_` and is shown only once.
Two choices on that dialog decide what the key can do. **This key acts as** picks the identity behind it: yourself, a **service account** that needs no seat in your identity provider, or another user. **Read-only** withholds write permanently. If you are wiring up an automation that should only ever read, see [Programmatic read-only access](/mcp/permissions#programmatic-read-only-access).
This is a different page from **Configuration → API Keys**, which issues `ak_` keys for the [Coverbase REST API](/api-reference/api-keys). The two key types are not interchangeable: an `ak_` key will not authenticate against the MCP server.
Add an `Authorization` header to whichever config shape your client uses:
```bash Claude Code theme={null}
claude mcp add --transport http coverbase https://mcp.coverbase.app/mcp \
--header "Authorization: Bearer cb_mcp_YOUR_KEY"
```
```json Config file theme={null}
{
"mcpServers": {
"coverbase": {
"type": "streamable-http",
"url": "https://mcp.coverbase.app/mcp",
"headers": { "Authorization": "Bearer cb_mcp_YOUR_KEY" }
}
}
}
```
Two limits worth knowing before you build on this:
* **Key generation is restricted to organization admins.** If the button isn't there, ask an admin in your organization to generate one for you.
* **A key carries the access of the identity it acts as.** A key that acts as you or another user carries that person's role, re-checked against their live membership on every request, so if their role changes the key follows it, and if they leave the organization the key stops working. For an unattended pipeline, have an admin generate the key as the **Service account**, which does not depend on any individual. A key that acts as anyone but you is always read-only.
If your integration only needs to read and write Coverbase records, rather than drive an AI assistant, the [REST API](/api-reference/api-keys) is usually the better fit. It is built for non-interactive use, and its `ak_` keys can belong to a true service account.
## Claude Code
Add the Coverbase server with the HTTP transport:
```bash theme={null}
claude mcp add --transport http coverbase https://mcp.coverbase.app/mcp
```
Then start Claude Code, run `/mcp`, and choose **Authenticate** to complete OAuth sign-in in your browser. The Coverbase tools are available once the status shows connected.
Use `--transport http` for the remote Coverbase server. Without it, the CLI assumes a local stdio command and the connection will fail.
## Claude.ai
In Claude, open **Settings → Connectors**.
Click **Add custom connector**, name it `Coverbase`, and paste the server endpoint.
Click **Add**, then **Connect**. You'll be redirected to Coverbase to sign in, review the requested scopes, and approve.
Return to Claude. The Coverbase tools are now available in your conversations.
## Claude Desktop
Open Claude Desktop, go to **Settings → Connectors**, and click **Add custom connector**. Name it `Coverbase`, paste the server endpoint, and click **Add**. Click **Connect** and sign in to Coverbase when prompted.
## Cursor
In Cursor's settings, open **MCP → Add new server**, or add the server to `~/.cursor/mcp.json`:
```json theme={null}
{
"mcpServers": {
"coverbase": {
"type": "streamable-http",
"url": "https://mcp.coverbase.app/mcp"
}
}
}
```
Cursor handles the OAuth flow in your browser on first use.
## VS Code
VS Code supports MCP servers natively in **GitHub Copilot agent mode**. Add the server to your `settings.json`:
```json theme={null}
{
"mcp": {
"servers": {
"coverbase": {
"type": "streamable-http",
"url": "https://mcp.coverbase.app/mcp"
}
}
}
}
```
Reload VS Code and sign in to Coverbase when Copilot prompts you.
## Microsoft Copilot Studio
Copilot Studio can call Coverbase as a Model Context Protocol tool.
In your agent, open **Tools → Add a tool → Model Context Protocol**, then add a new MCP server.
Set the transport to **Streamable HTTP** and enter the server endpoint `https://mcp.coverbase.app/mcp`.
Choose **OAuth 2.0** authentication. Copilot Studio uses dynamic discovery to find the authorization server, so no manual endpoint configuration is required. Complete sign-in to Coverbase to finish.
Copilot Studio probes the RFC 8414 §3.1 path-insertion discovery variant (`/.well-known/oauth-authorization-server/{path}`). The Coverbase server serves authorization-server metadata at that path, so dynamic discovery works out of the box. If discovery fails with "Could not discover authorization server metadata," confirm you entered the full `/mcp` endpoint.
## Microsoft ecosystem and other agents
Coverbase works with any framework that speaks MCP over OAuth 2.0 with Streamable HTTP transport, including **Semantic Kernel**, the **Microsoft Agent Framework** (AutoGen), and **Azure AI Foundry** agents. Register `https://mcp.coverbase.app/mcp` as a remote MCP server / tool in your framework's MCP client and let it run the OAuth flow.
Other popular clients:
* **Cline (VS Code):** open the Cline **MCP Servers** panel and add a new remote server with the Coverbase endpoint.
* **Goose:** run `goose configure`, choose to add a remote MCP server, and enter the endpoint.
* **MCP Inspector:** run `npx @modelcontextprotocol/inspector`, enter the endpoint, authenticate, and exercise tools directly.
## Clients without remote MCP support (mcp-remote)
For clients that only support local **stdio** servers, bridge to the remote server with [`mcp-remote`](https://www.npmjs.com/package/mcp-remote):
```json theme={null}
{
"mcpServers": {
"coverbase": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.coverbase.app/mcp"]
}
}
}
```
`mcp-remote` proxies the connection and handles the OAuth handshake in your browser on first use.
## Other clients
Any client that supports MCP with OAuth 2.0 and Streamable HTTP transport should work. The OAuth discovery documents are published at `https://mcp.coverbase.app/.well-known/oauth-protected-resource` and `https://mcp.coverbase.app/.well-known/oauth-authorization-server`. Point your client at the server URL and the rest is standard.
No tools appearing, permission denied errors, write actions not executing, `403 Forbidden` during authentication, and other common issues.
# Anthropic Connectors Directory
Source: https://docs.coverbase.com/mcp/connector-directory
Coverbase in Claude's official Connectors Directory: one-click install, branded card, and a published security review.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Coverbase is published in Anthropic's [Connectors Directory](https://claude.com/docs/connectors), the curated list of MCP servers that Claude users can add to their workspace in a single click. Listed connectors ship with a branded card (logo, tagline, screenshots) and a security review from Anthropic's team.
## What this means for you
Add Coverbase from **Settings → Connectors → Browse directory** in Claude.ai. No URL to copy, no permission prompts to dismiss.
The Coverbase logo, tagline, and supported tools render natively in the connectors picker, the same visual treatment as built-in connectors.
Anthropic reviews every directory submission against their [Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy) for safety, security, and tool design before listing.
The directory entry points at the same `mcp.coverbase.app/mcp` endpoint as a custom connector. Data access is still scoped to your Coverbase user and your org's permissions.
## How to add Coverbase from the directory
Click **Settings → Connectors** in the sidebar, then **Browse directory**.
Search for *Coverbase* or filter by the **GRC / Risk** category.
Click **Add**, then **Authorize** to complete the OAuth sign-in in your browser. You'll be sent to Coverbase to confirm the connection.
The Coverbase tools appear in your Claude session immediately. Try one of the [example prompts](/mcp/example-prompts).
Already added Coverbase as a custom connector? You can keep it: the directory entry and a custom entry both point at the same server. Custom connectors render with a generic globe icon, so most users prefer to remove the custom entry and re-add from the directory once they have access.
## What's included in the directory listing
* **Server endpoint**: `https://mcp.coverbase.app/mcp`
* **Transport**: Streamable HTTP (stateless)
* **Auth**: OAuth 2.0 + PKCE
* **Tools**: All 12 dispatcher tools (vendor / assessment / finding / engagement / control / questionnaire / RFP / radar / platform queries, the `get_report` aggregations, the `mutate` write dispatcher, and `mcp_capabilities` discovery)
* **Resources**: Direct URI reads for vendors, assessments, engagements, controls, and findings
* **Prompts**: TPRM workflow templates (vendor onboarding, portfolio risk briefing, and more)
## Custom connector vs directory entry
| | Custom connector | Directory entry |
| - | - | - |
| Install | Paste URL `https://mcp.coverbase.app/mcp` | One click from Browse directory |
| Logo in Claude.ai | Generic globe | Coverbase branded card |
| OAuth | Same Coverbase OAuth flow | Same Coverbase OAuth flow |
| Tool surface | Identical | Identical |
| Security review | Self-managed | Reviewed by Anthropic |
| Updates | Manual reconnect for major changes | Anthropic notifies on breaking changes |
Both routes connect to the same production server and inherit the same Coverbase permissions. The directory entry is purely an installation and discovery improvement.
## Other clients
The directory listing is a Claude.ai surface. To use Coverbase from Claude Code, Claude Desktop, Cursor, VS Code, Microsoft Copilot Studio, or any other MCP client, follow the [Connecting clients](/mcp/connecting) guide. The server endpoint, OAuth flow, and tool surface are identical regardless of where you connect from.
# Example prompts
Source: https://docs.coverbase.com/mcp/example-prompts
Realistic prompts that exercise the core MCP server workflows.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Use these as inspiration, not a script. The patterns below cover the workflows most customers run on a daily and weekly basis.
## Vendor intake
The full intake request runs in conversation. You don't need to say "intake" for any of these; the assistant recognizes the intent. See [Vendor intake in chat](/mcp/vendor-intake) for the whole flow.
> I want to start using Northwind Analytics for product analytics.
The assistant opens an intake session, reads your portal configuration to see which steps your org enabled, researches Northwind and confirms with you that it has the right company, offers a menu of concrete use cases and in-scope services, surfaces any existing vendor of yours that already covers analytics, runs the screening your portal configures, then walks the inherent risk questionnaire with you one question at a time. Every write asks first.
> My team needs a load testing tool and we're looking at Loadspin. Can we buy it?
Same flow. "Can we buy this" and "my team needs" are intake requests, not questions about policy. The assistant starts the request rather than answering in the abstract.
> Is Acme approved for us to use?
The assistant resolves the name to a vendor, checks its onboarding status, and reports it. If there's no approved record, it offers to start the intake rather than stopping at "no".
> We're about to sign with Mixpanel. Do we already have something that does this?
Vendor matching ranks your existing vendors against the request and surfaces prior relationships, so a duplicate purchase gets caught before the request is filed rather than during review. Web alternatives appear too, if your portal enables them.
> That's the wrong Acme. I mean the payments one, acme.io, not the logistics company.
The assistant takes the correction and re-runs matching or picks another candidate. An unconfirmed match is never carried forward into the request.
> Where did my Datadog request get to? Let's finish it.
The assistant finds the open session, reports which questions are still unanswered or still carrying unconfirmed AI drafts, and resumes the walkthrough there.
> What steps does our intake process include?
The assistant reads your portal configuration and reports which steps are enabled and which your org turned off. Useful when you're not sure whether pre-qualification or web alternatives are part of your flow.
> Add Figma as a vendor record only. Skip the intake questionnaire, we already did the review offline.
The only path to a bare vendor record. The assistant states plainly that the vendor will carry no due diligence, waits for you to confirm that, and only then creates it. Requests that don't explicitly ask to skip intake go through the full flow instead.
### Reviewing what comes in
> Walk me through everything waiting in the intake queue.
The assistant lists pending-review sessions and takes them one at a time: the requester's use case and services, the enrichment and duplicate readout, the pre-qualification verdict per criterion, and the questionnaire answers with their inherent risk score.
> Review the intake request for Marqeta and tell me whether anything looks off.
The assistant pulls the full submission, flags weak or inconsistent answers, and proposes approve, reject, or request-follow-up. The decision is a write, so it waits for your confirmation.
> Their data-types answer is too vague. Send it back and ask what customer PII flows to them.
The assistant proposes the follow-up request with your question attached, confirms, and returns the session to the requester.
Submitting an intake request is not approval. At the end of the requester flow a vendor record may exist, but it sits in **Created** status and nobody should start using the vendor until a reviewer decides the request.
## Portfolio and subprocessor analysis
> Which of our vendors use AWS as a subprocessor, and what is the current risk tier for each?
The assistant calls `query_radar(kind="soc2_nth_party")` with relevant aliases in `llm_query_terms` (AWS, Amazon Web Services, S3, EC2), gets back the list of dependent vendors, then calls `query_vendors(kind="risk_summary")` for each to surface tier and open findings count.
> A major Northwind outage is happening. Show me every vendor in our portfolio that depends on Northwind, sorted by criticality.
Same pattern, scoped to Northwind. The assistant can also pull recent radar alerts for the affected vendors to see if any have already filed incident notifications.
> Build me a one-page report of our top 10 highest-risk vendors with their key open findings.
The assistant calls `get_report(report_name="portfolio_risk", top_n=10)`, then drills into each vendor with `query_vendors(kind="detail")` to extract the relevant findings.
## Vendor profiles and assessments
> Give me a full risk summary for Acme Corp, including any open findings and recent radar alerts.
The assistant calls `query_vendors(kind="search")` to resolve the name to an ID, then `query_vendors(kind="detail")` to pull the consolidated profile in a single call.
> Summarize assessment cbqsrw\_abc123 and list the controls that need human review.
The assistant calls `query_assessments(kind="detail")` and surfaces the control evaluations that are flagged or have open findings, so the reviewer can focus on what matters.
> Give me the complete AI summary for the HubSpot assessment. I want the decision summary, the key business risks, the required conditions, and the vendor remediation message.
`query_assessments(kind="detail")` carries only the opening of the summary and says so. The assistant calls `query_assessments(kind="summary")` for the whole report, and pages through it if it runs long.
> List every completed assessment this quarter with its outcome and residual risk level, as a table.
Both fields are on each `query_assessments(kind="search")` row, so this is one call per page rather than one call per assessment. See [Replacing the assessment export](/mcp/assessment-exports) if you are feeding a dashboard.
> Which assessments did we conditionally approve last quarter, and what conditions did we attach to each?
The outcome is on the search rows, so the assistant filters there first, then reads the summary report for only the matching assessments to pull the conditions out of the narrative.
> What does the assessment backlog look like? How many are in progress, and who owns each?
The assistant pulls `get_report(report_name="review_queue")` for the count of open / in-progress assessments and their owners, or `get_report(report_name="assessment_metrics")` for the rolling-window throughput view. (Assessment statuses are workflow stages such as `collecting_documents`, `analyzing_questionnaire`, and `review_evals`; there is no single `in_progress` status, so the review-queue report is the right tool for backlog.)
## Evidence out of documents
Coverbase reads the documents and returns the passage the answer rests on. Full guide: [Asking your documents a question](/user-guides/document-evidence-pull).
> Does Acme encrypt customer data at rest? Check their SOC 2.
The assistant resolves Acme, calls `query_vendors(kind="document_evidence")` scoped to that vendor, and gets a run id back rather than an answer. A model picks the one or two documents most likely to hold it, reads them, and locates the passage. A minute or two later the assistant calls `query_vendors(kind="document_evidence_result", run_id=...)` and reports the answer with its verbatim quote, the page, a cropped image of the highlighted passage, and a link that opens the document there.
> What is the termination notice period in Acme's MSA, and quote the clause.
Naming the document type narrows the candidate set before anything is read. The quote comes back verbatim, so it can go straight into a negotiation note.
> In the Acme penetration test report, were any critical findings left unresolved?
Naming a document skips the selection step and reads that document.
> I need evidence that Northwind does background checks on staff with production access. Find it and give me something I can cite.
The answer arrives with a page citation and a permanent Coverbase link. Paste the link into the assessment rather than the image: the image link expires after about an hour.
> Does Acme have a documented incident response SLA?
If the documents read do not address it, the response says so rather than inferring an answer. Ask the assistant to widen the scope (drop the document type, raise the document limit) before concluding the control does not exist.
## Vendor intelligence
> Is Acme Corp a real registered company? Show me the legal entity and where you got it from.
The assistant calls `query_vendors(kind="company_registration")`, which returns the validated corporate identity from GLEIF, OpenCorporates, and SEC EDGAR (official registered name, status, jurisdiction, and identifiers) with a link to each register's record. If nothing matched confidently, it says so rather than offering the nearest guess.
> What's the security posture for Acme Corp, and what should I raise with them?
The assistant reads the vendor's outside-in security posture: the rating and grade, the per-factor breakdown with the observed values behind it, the ranked next steps (most urgent first, each naming the evidence it rests on), and what changed since the previous scan. Ask it to draft the questions and it quotes the observed values, such as `p=none` or the CVE identifier, rather than paraphrasing them.
> What's the financial health score for Acme Corp, and has it moved in the last year?
The assistant calls `query_vendors(kind="financial_health")` and reports the score, risk band, **confidence tier**, pillar breakdown, and 3- and 12-month movement, along with the sources behind each figure and any that were unavailable.
> Which of my tier-1 vendors are in the High or Very High financial risk bands?
The assistant resolves the vendor set, then pulls `query_vendors(kind="financial_health")` per vendor. Ask it to group by confidence tier: a Tier C score is inferred from signals and a Tier A score is computed from filed statements, so the two are not directly comparable and a ranking that mixes them is misleading.
> Is the entity on the Acme contract the same one that's registered and in good standing?
The assistant pulls `query_vendors(kind="company_registration")` for the registered legal name and status and compares it against the counterparty on the contract. A mismatch between the contracting entity and the registered entity is a real finding, not a formatting difference.
## Program health and continuous monitoring
> What is happening across our TPRM program this week? Show me recent assessments, open findings, and radar alerts.
The assistant calls `get_report(report_name="org_activity", days=7)` with reasonable limits. This is the single most useful prompt for a daily standup or weekly review.
> Show me every vendor with overdue findings and their owners so I can chase them.
The assistant calls `query_findings(kind="list_detailed")` org-wide with a status filter for open and a date filter for past-due, then groups by assignee.
> Are there any new radar alerts on our tier-1 vendors in the past 24 hours?
The assistant calls `query_radar(kind="alerts")` filtered by vendor ID for the tier-1 list, or asks `get_report(report_name="org_activity", days=1)`.
## Contracts and obligations
> What contracts expire in the next 90 days, and which of those vendors have unresolved findings?
The assistant calls `query_engagements_contracts(kind="contracts")` with the date filter, then for each result calls `query_findings(kind="search")` scoped to that vendor.
> Are there any obligations coming due next month that have not been assigned to anyone?
The assistant calls `query_engagements_contracts(kind="obligations")` filtered by due date and missing assignee.
## Sourcing and RFPs
> Draft an RFP to replace our applicant tracking system for about 12 recruiters. It has to integrate with our HRIS and Microsoft 365, and we will not grant tenant-wide mailbox access.
The assistant calls `mutate(entity="rfp", action="draft_brief")`, which writes nothing and returns a proposed name, description, narrative and timeline for you to correct.
> Who should we invite? Show me what each is known for and what to watch out for.
`mutate(entity="rfp", action="research_vendors")` returns five to ten candidates with the reasoning behind each. Still no write.
> Suggest requirements and questions for it, then create the RFP with those and the four vendors I picked.
`suggest_requirements` and `generate_questions` propose the rubric and questionnaire; `create`, with `confirm: true`, builds the RFP, rubric, questionnaire, vendor records and invitations in one transaction, as a draft.
> Run it silently and tell me how they stack up.
`simulate_submissions` researches how each invited vendor would most plausibly answer, then `compare` reads the whole set together. Every rendering states that these are researched estimates, not vendor responses. A vendor who already sent a real response is skipped.
> What did Greenhouse say about mailbox scopes?
`query_rfps(kind="submission_answers")` returns that submission's answers, each labelled with whether it came from the vendor or from research.
## Bill of materials
> Show me the latest software bill of materials for vendor Acme and list its components.
The assistant calls `query_vendors(kind="search")` to resolve the name, then `query_vendors(kind="bill_of_materials", vendor_id=...)` to pull the current applied BOM and its components in one call.
> Does Acme's current SBOM include any GPL-licensed components?
Same `bill_of_materials` call, then the assistant filters the returned components by their `licenses`.
> What AI models and datasets are in Acme's AIBOM?
The assistant pulls the latest BOM and surfaces the `machine-learning-model` and `data` components.
> Pull the components from Acme's latest hardware BOM.
The assistant calls `query_vendors(kind="bill_of_materials", vendor_id=...)` and lists the hardware components.
> List every bill of materials we've received from Acme over time. Which one is currently applied?
The assistant calls `query_vendors(kind="bill_of_materials_history", vendor_id=...)`. The list comes back newest first; the first entry is the applied one.
> Has Acme ever shipped a BOM that contained `openssl`? Show the history.
The assistant calls `query_vendors(kind="bill_of_materials_history", vendor_id=...)` and checks each BOM's components for the match, tracing every hit back to its source document.
**What these call:** `query_vendors(kind="bill_of_materials", vendor_id=...)` or `query_vendors(kind="bill_of_materials_history", vendor_id=...)`, both read-only and user/org-scoped. See the [Bill of Materials API](/api-reference/bill-of-materials#mcp-assistant-access) for the full argument list.
## Write actions, with confirmation
Every write tool requires the assistant to propose the action in chat and wait for your explicit approval. The examples below show the pattern.
> Add a note to vendor Acme Corp: following up with their security team next week.
The assistant proposes: *"I am about to add a note to Acme Corp with the text 'following up with their security team next week.' Confirm?"* After your approval, it calls `mutate(entity="note", action="add", data={..., "confirm": true})`.
> Create a finding on assessment cbqsrw\_abc123 titled "Missing encryption at rest evidence" and assign it to me.
The assistant proposes the finding (title, body, assessment ID, assignee), waits for confirmation, then calls `mutate(entity="finding", action="create", data={..., "confirm": true})`.
> Update the risk tier of vendor Globex to Tier 1.
The assistant proposes the change to the vendor status, confirms, then calls `mutate(entity="vendor", action="update", data={..., "confirm": true})` with the relevant status ID.
> Log a radar event for Acme Corp: they disclosed a data breach today.
The assistant proposes the event (name, summary, impact type, vendor), waits for confirmation, then calls `mutate(entity="radar_event", action="create", data={..., "confirm": true})`.
> That radar alert about Acme is a duplicate. Dismiss it and suppress similar ones.
The assistant proposes the dismissal (alert ID, reason, `suppress_similar`), confirms, then calls `mutate(entity="radar_alert", action="dismiss", data={..., "confirm": true})`.
> Kick off a reassessment of Acme Corp because of that breach event.
The assistant lists reassessments via `query_radar(kind="reassessments")` to check for an existing one, then proposes a new reassessment (radar event, vendors, optional plan) and calls `mutate(entity="reassessment", action="create", data={..., "confirm": true})`. This never opens a case.
## Tuning the AI
> Which of our controls raise issues most often? I think some are misfiring.
The assistant calls `get_report(report_name="control_flag_rates")` to rank controls by issue-flag rate across recent assessments, with a volume floor so a control evaluated twice doesn't top the list. Pass `format='csv'` if you want it in a spreadsheet.
> Go through the flagged issues on assessment cbqsrw\_abc123 with me and clear the ones that aren't real.
The assistant walks each flagged evaluation with its evidence, and for the ones you clear calls `mutate(entity="eval", action="update", data={..., "outcome": "not_an_issue", "confirm": true})`.
> That control keeps flagging vendors who do have MFA. Rewrite its guidance.
The assistant proposes new expectation, evaluation instruction, or evidence requirement text, confirms, then calls `mutate(entity="control", action="update", data={..., "confirm": true})`. Material edits create a new version rather than overwriting the old one. Re-run the analysis with `mutate(entity="assessment", action="rerun", ...)` to re-evaluate against the new guidance.
## Related
Twenty scripted workflows you can invoke by name, including `weekly_briefing`, `submit_intake_request`, and `tune_control_guidance`.
Every route these prompts resolve to, and the parameters each accepts.
Every Consolidated Assessment Report column mapped to the call that returns it, with sample input and output.
# Coverbase MCP Server
Source: https://docs.coverbase.com/mcp/overview
Let AI assistants query and manage your TPRM program through natural conversation.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The Coverbase MCP server lets AI assistants and agentic tools query and manage your third-party risk and procurement program through natural conversation. Ask about vendors, assessments, findings, contracts, obligations, and subprocessor exposure, and the assistant pulls answers directly from your Coverbase account, scoped to your permissions.
The server implements the [Model Context Protocol](https://modelcontextprotocol.io), an open standard for connecting AI assistants to external systems. It works with any MCP-compatible client.
## Supported clients
claude.ai web, Claude Desktop, Claude for Chrome
Anthropic's command-line agentic coding tool
The AI-native IDE
GitHub Copilot agent mode (native MCP)
MCP tools for Copilot agents
The VS Code coding agent
Block's open-source AI agent
The official Anthropic debugging client
If your tool speaks MCP over OAuth 2.0 with Streamable HTTP transport, it will work with our server. Email [support@coverbase.ai](mailto:support@coverbase.ai) if you'd like us to add yours to the test matrix.
## What you can do
The server exposes 12 tools, each dispatching many operations, across read and write capabilities.
File a complete vendor intake request in conversation: the assistant researches the vendor and confirms its identity with you, surfaces existing vendors that already cover the need, runs the pre-qualification and duplicate checks your portal configures, then walks the inherent risk questionnaire one question at a time. Reviewers can work the pending queue the same way, approving, rejecting, or requesting follow-up. See [Vendor intake in chat](/mcp/vendor-intake).
Search vendors by name, status, tier, owner, or tags. Pull a full vendor profile in one call: people, assessments, findings, contracts, engagements, obligations, radar alerts, security cases, and SOC 2 documents. Read a vendor's latest applied bill of materials (SBOM, AIBOM, HBOM, SaaSBOM) and its components, or its full BOM upload history. Surface portfolio-wide views including highest-risk vendors, evidence health, assessment metrics, Zero Touch Score rankings, and your risk register, and run what-if risk scenarios.
Search assessments by vendor, status, or assignee. Get full assessment detail in one call: control evaluations, findings with titles, people, supporting documents. List control sets, controls within a set, and per-control evaluation results. Start new assessments, update fields, and manage assessment plans.
Search findings scoped to a vendor or assessment, or org-wide, with full titles, categories, assignees, due dates, and status. List follow-ups attached to assessments. Search and update obligations extracted from vendor documents. Create new findings or obligations with explicit confirmation.
Search contracts by vendor or status, and get full contract detail. List vendor engagements and vendor documents (evidence files) for a vendor or org-wide. Get evidence health summaries.
List RFPs and read one in full: timeline, rubric, invited vendors, submissions and their answers, and the stored cross-vendor comparison. Draft a brief, research candidate vendors, create and publish the RFP, compare submissions, and award it, each write with confirmation. See [How to run an RFP](/user-guides/running-an-rfp).
Search across all vendors' SOC 2 reports and custom relationships to find which vendors depend on a specific nth-party. The question that takes hours in most TPRM tools and seconds here: "which of our vendors use AWS as a subprocessor?"
Rank controls by how often they flag an issue across recent assessments to find the false-positive-prone ones, then tune a control's expectation, evaluation instructions, or evidence requirement so it stops misfiring. Material edits create a new version rather than overwriting. Clear individual false positives on a single assessment, and re-run the analysis against the new guidance.
List radar alert events for a single vendor or across the org. List and update radar detectors configured for the org. Seed a radar event manually, dismiss a noisy alert (optionally suppressing similar ones), and start a reassessment from an event with its impacted vendors.
Get an org activity digest in one call: recent assessments, open findings, radar alerts, audit trail entries, and notifications. List the audit trail for any supported object.
List and add notes on any platform object. List and update tags, custom field configurations, custom field values, workflow automations, assessment plans, questionnaires, status labels, and org users.
Every route on all 12 tools: the read `kind` values, the report catalog and their parameters, and the complete write matrix.
Every tool that creates, updates, or deletes data requires a `confirm` parameter set to `true`. The assistant is expected to surface the proposed change in chat and wait for your approval before executing. This human-in-the-loop pattern applies uniformly across all write tools.
## Server endpoint
```text theme={null}
https://mcp.coverbase.app/mcp
```
## Connecting
`claude mcp add --transport http coverbase https://mcp.coverbase.app/mcp`
Add a custom connector in Settings → Connectors
Add a custom connector in Settings → Connectors
Add as a remote MCP server in Cursor settings
Native MCP in GitHub Copilot agent mode
Add as a Model Context Protocol tool
Any MCP client with OAuth 2.0 and Streamable HTTP transport
## Requirements
* An active Coverbase account on a plan that includes API access.
* An MCP-compatible AI assistant or client.
* The MCP server uses OAuth 2.0. Your permissions in Coverbase determine what the connected assistant can see and do.
Run a full intake request in conversation: identity confirmation, alternatives, screening, and the questionnaire.
Every route on all 12 tools, with the parameters each accepts.
Twenty scripted workflows you can invoke by name instead of describing.
Realistic phrasing for the workflows customers run daily and weekly.
How read-only versus read/write is decided, and how it maps to your Coverbase role.
How we handle credentials, what we log, what we don't retain, and how to revoke access.
# Roles and permissions
Source: https://docs.coverbase.com/mcp/permissions
How the MCP server enforces read-only versus read/write access, why it inherits the connected user's Coverbase role, and the controls that keep every tool call least-privilege.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The Coverbase MCP server does not have its own permission system. Every tool call runs as the person who authorized the connection, with exactly the access that user already has in Coverbase, no more. There are no separate MCP credentials, no service identity that sees more than the user, and no way for the assistant to escalate beyond what the user could do in the dashboard.
This page explains how that works end to end: how a request is authenticated, how a role is resolved, and how read-only versus read/write access is decided and enforced.
**The short version.** Two things decide access: the **role** of the identity connecting, and the **scopes** on the credential. **Admins** and **Members** can write; **Guests** and **Siloed Members** are read-only. On top of that, an API key can be minted **read-only**, which withholds write regardless of role. Change someone's role in Coverbase and it takes effect on their next request; there is nothing separate to re-issue.
## Permission inheritance
When a client connects, the user signs in to Coverbase through OAuth 2.0 and authorizes the connection. From that point on, every tool the assistant calls is evaluated against **that user's live organization membership**. The connector is a delegate, not a privileged service account.
Three properties follow from this design:
The assistant can never see or do more than the connected user could do by logging into the dashboard themselves.
Permissions are read from the user's organization membership, not from a static config baked into the connector or copied at install time.
Every call is scoped to the user's organization. The client never supplies an organization ID; the server derives it from the authenticated session.
## Role-to-access matrix
Coverbase organization roles map to MCP access as follows.
| Role | Can connect to MCP? | Read tools | Write tools |
| - | - | - | - |
| **Admin** | Yes | Yes | Yes |
| **Member** | Yes | Yes | Yes |
| **Siloed Member** | Yes | Yes | No (read-only) |
| **Guest** | Yes | Yes | No (read-only) |
| **Auxiliary Member** | No | - | - |
| **Custom role** | No | - | - |
| **Service Account** | API key only | Yes | No (read-only) |
A few specifics:
* **Read access** (search vendors, pull assessment detail, list findings, run portfolio reports, and so on) is available to every role that can connect.
* **Write access** (creating or updating vendors, assessments, findings, obligations, notes, tags, and other records) is reserved for **Members** and **Admins**.
* **Auxiliary Members** cannot use the MCP server at all, and receive a `403` if a token for one is ever presented.
* **Custom roles** cannot connect. The write guard cannot express a custom role's permissions, so rather than silently forcing a possibly write-capable user to read-only, the server refuses the connection. Give the user one of the default roles above.
* **Service Accounts** are non-interactive by design, so they cannot sign in through OAuth or a dashboard session; those paths still return `403`. They *can* hold an API key, which is what makes a programmatic read-only connection possible without a human seat. A service account can never write through MCP.
The MCP write boundary is deliberately conservative. Write access through the connector is limited to Members and Admins, so it is **never broader** than what the same user could do in the dashboard. For some roles it is intentionally tighter. If you need a user to make changes through an assistant, give them the Member or Admin role.
## How a request is authorized
Every request flows through the same gate, regardless of which client or token type it uses. There is no path that skips role resolution.
The server accepts three token formats on the `Authorization: Bearer` header: an OAuth 2.0 access token issued to a remote MCP client, a dashboard SSO session token, or a long-lived Coverbase-issued MCP API key. Anything else is rejected with `401`.
The user's organization role is resolved from their **current** membership record, not from anything cached in the client. For API-key and session tokens, the membership is looked up on every request. For OAuth tokens, the role is bound to the token from live membership at authorization time and **re-validated every time the token is refreshed** (see [Live revalidation](#live-revalidation)).
If the resolved role is not one of the connectable roles (Guest, Siloed Member, Member, Admin, plus Service Account on an API key), the request is rejected with `403` before any tool runs. Auxiliary Members and custom roles are not connectable.
Read tools proceed for any connectable role. Write tools pass through an additional guard described in [Write protection](#write-protection) before they touch any data.
The organization is taken from the authenticated session and applied to every query automatically. The client cannot widen the scope by passing a different organization ID; there is no parameter to do so.
## Write protection
Read-only versus read/write is not a single switch: a write tool only executes when **three independent conditions** are all satisfied. Any one of them failing returns a clear, non-destructive error instead of performing the change.
The connected user's role must be **Member** or **Admin**. Guests and Siloed Members receive a message explaining that their role cannot run write tools, and are pointed to ask a Member or Admin.
The credential must carry the **`mcp:write`** scope. An API key minted read-only, or an OAuth token issued without it, produces a strictly read-only connection even for a user whose role would otherwise allow writes. (See [Scopes](#scopes).)
Every write tool requires an explicit `confirm=true` argument. Without it, the tool returns a precondition error rather than executing, so the assistant is forced to surface the proposed change to you and wait for your approval before anything is written.
These checks are applied **server-side**, inside the write guard, before any database write. They do not rely on the client or the model behaving correctly. A misbehaving or compromised client cannot bypass the role check, the scope check, or the confirmation requirement.
## Scopes
The server defines two scopes:
| Scope | Grants |
| - | - |
| `mcp:read` | Access to all read tools (search, detail, reports). |
| `mcp:write` | Access to write tools, in combination with a write-capable role and explicit confirmation. |
Every credential carries `mcp:read`. Whether it also carries `mcp:write` is fixed when the credential is issued:
* **API keys** store their scopes on the key itself. Tick **Read-only** when you generate one under **Configuration → MCP Server** and the key never carries `mcp:write`, not now and not if the owner is promoted to Admin later. The key list shows the grant on each key.
* **OAuth tokens** are issued with both scopes by default. The authorization endpoint also accepts a narrower `scope` request, so a client can ask for `mcp:read` alone.
A read-only credential is not merely refused at the last moment. The `mutate` tool is **hidden** from such a connection: it does not appear in the client's tool list, and `mcp_capabilities` reports no mutations. The assistant never proposes a change it cannot make, so you are never asked to confirm a write that was going to fail.
## Programmatic read-only access
The common case is a pipeline, a scheduled report, or an internal assistant that should read Coverbase and never change it. You do not need a human seat for this.
Go to **Configuration → MCP Server** and choose **New API key**.
**Service account** is the usual answer: a built-in non-human identity that needs no seat in your identity provider and never signs in. Choose **Another user** instead to attribute the key's activity to a particular member, such as a Guest kept for reporting.
Either choice makes the key **read-only automatically**. A key that authenticates as someone else can never write, so a change is never recorded under a name that did not make it.
The secret is shown once. Send it as `Authorization: Bearer cb_mcp_...` from your client. See [Connecting clients](/mcp/connecting).
You keep control of a key you minted for a service identity: it appears in your key list and you can revoke it, even though it authenticates as something else. For what shows up in the audit trail once it is running, see [Attributing a key that acts as a service account](#attributing-a-key-that-acts-as-a-service-account).
**Want a guaranteed read-only connection?** Any one of these is sufficient on its own, because the write guard requires *both* a write-capable role *and* the write scope:
1. Mint the API key **read-only**.
2. Bind the key to a **service account** or another user, which forces read-only.
3. Connect with a **Guest** or **Siloed Member** account; their role blocks writes regardless of scope.
## Live revalidation
Because permissions are resolved from live membership, changes you make in Coverbase propagate without any re-install or token re-issuance on the user's side.
* **API-key and session tokens** look up the user's membership on **every request**. If the user has been removed from the organization, the request is rejected with `403`, even if the token itself is still otherwise valid. A key's *scopes* do not follow the role: a read-only key stays read-only through any promotion, which is what makes it safe to hand to an automation.
* **OAuth tokens** bind the role at authorization time and **re-check live membership on every refresh**. A user who is demoted (for example, Member → Guest) or removed from the organization cannot keep using a previously elevated token past its expiry: the next refresh either downgrades the role baked into the new token or fails outright. Access tokens last up to 24 hours and clients refresh silently, so a role change on an OAuth connection takes effect within a day at most.
This means a demotion is also a downgrade of MCP access, and a removal is a revocation, without anyone needing to touch the connector. For API keys it is immediate; for OAuth connections it lands at the next token refresh. Revoking an MCP API key under **Configuration → MCP Server** stops it at once. Disconnecting a client removes the tokens that client holds, but Coverbase has no separate switch to invalidate an OAuth access token that was already issued.
## What this means in practice
The assistant can search vendors, pull the vendor's full profile, list findings and assessments, and run reports; all read operations succeed. The update is **blocked by the role check** and the assistant is told the user's role cannot perform writes. No data is changed.
The role check passes (Member is write-capable) and the default token carries `mcp:write`. The assistant proposes the new finding and waits. Once you confirm, it re-runs the tool with `confirm=true` and the finding is created, and the action is recorded in the audit trail.
On the user's next request (API key/session) or next token refresh (OAuth, within 24 hours), the new Guest role takes effect. Subsequent write attempts are rejected. There is nothing to reconfigure on the user's machine.
An API key or session token fails with a `403` on the next request, because there is no active membership to resolve a role from. An OAuth connection keeps working until its current access token expires (up to 24 hours), and the refresh then fails.
## Auditability
Every tool call, read or write, is logged with the connected identity, the tool name, the parameters, a timestamp, and the outcome. Write actions taken through the MCP server land in the same Coverbase audit trail as actions taken in the dashboard, so administrators have one consolidated record of who did what, regardless of whether it happened through the UI or an assistant.
### Attributing a key that acts as a service account
A reasonable question about any non-human credential: if it changes something, whose name is on it?
For MCP keys the answer is that it cannot change anything. A key bound to a service account or to another user is read-only, and a service account is additionally excluded from the write-capable roles. **A bound key never produces a write in your audit trail**, so there is no such thing as a change you cannot trace to a person. Only a key that acts as *you* can write, and those entries carry your name exactly as if you had made the change in the dashboard.
What you can still see for a bound key:
Creating and revoking an MCP key are recorded in **Configuration → Audit Logs** under **Integrations**, attributed to the admin who did it, with the key's name. The key also stores that admin internally, so a key always traces back to a person even though it runs unattended.
Every tool call the key makes is logged with the connected identity, the tool, the arguments, and the outcome. Read activity is recorded, not only writes.
**One service account identity is shared by every integration in your organization**, and it is the same identity behind your REST API keys. Two MCP keys bound to it are not distinguishable from each other in the per-call logs, which record the identity rather than the individual key.
So issue **one key per integration** rather than reusing a single key across several, and give each a name that says what it is for. That way the provisioning record in the audit log tells you which integration was set up when and by whom, and revoking one key stops exactly one integration instead of all of them at once.
This differs from the [REST API](/conventions#public-api-audit-log), where each request records the calling `ak_` key's id and name alongside the shared identity. Per-key attribution on individual MCP tool calls is not available today.
If you need machine activity attributed to a distinct named identity rather than the shared service account, bind the key to a dedicated user instead: create a **Guest** for it and use **Another user** when generating the key. That costs a seat in your identity provider, which the service account option avoids, so it is a trade between attribution granularity and provisioning overhead.
Authentication, transport security, what we log, what we don't retain, and how to revoke access.
# Canned prompts
Source: https://docs.coverbase.com/mcp/prompts
Twenty scripted TPRM workflows you can invoke by name instead of describing what you want.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Alongside its tools, the server publishes **prompts**: scripted multi-turn workflows you invoke by name. Each one hands the assistant a sequence to follow, so you get the same shape of output every time instead of whatever the model improvises.
How you invoke one depends on your client. In Claude, prompts appear in the attachment or slash menu once the connector is added. In other clients, look for "prompts" or "templates" in the MCP integration.
Prompts are a convenience, not a gate. Everything below is reachable by describing what you want. The value is repeatability: the same review runs the same way each week, and the steps that are easy to skip don't get skipped.
Prompts that lead to a write always instruct the assistant to get your explicit confirmation first. A prompt never grants standing permission to mutate data.
## Vendor intake
**Argument:** `vendor_name`
Files a new vendor intake request end to end: opens the session, reads your portal configuration, researches and confirms the vendor's identity, surfaces existing vendors that already cover the need, runs your configured screening, and walks the inherent risk questionnaire one question at a time.
See [Vendor intake in chat](/mcp/vendor-intake) for the full flow.
**No arguments.**
Walks every pending-review intake session in turn: the requester's use case and services, the enrichment and duplicate readout, the screening verdict, and the questionnaire answers.
**Argument:** `intake_session_id`
Approve, reject, or request follow-up on one intake session.
**Arguments:** `vendor_name`, `use_case` (optional)
Adds a bare vendor record with **no due diligence**. Only for when you explicitly want to skip intake. The assistant states what you're giving up before it creates anything.
## Assessments and controls
**Argument:** `assessment_id`
Walks approving or sending back one assessment.
**Argument:** `assessment_id`
Walks one assessment's flagged issues, clears the false positives, and suggests guidance fixes so the same control stops misfiring next time.
**Argument:** `days` (default 180)
Finds over-flagging controls across recent assessments and tunes their AI guidance to cut false positives. The companion to `false_positive_review`: one fixes the instance, this one fixes the cause.
**Argument:** `assessment_id`
Produces an executive-ready report for a single assessment.
**Argument:** `vendor_name`
Generates a pre-onboarding due diligence checklist for a new vendor.
## Findings, evidence, and obligations
**No arguments.**
Walks overdue and open findings, grouped so you can chase the right owners.
**No arguments.**
Identifies and prioritizes vendors with expiring or missing evidence.
**Argument:** `vendor_id`
An evidence health audit for one vendor.
**Arguments:** `vendor_name`, `question`
Answers a plain-English question out of a vendor's stored documents. Resolves the vendor, looks at what evidence exists, starts a pull, waits for it, then reports each answer with its verbatim quote, page number, confidence, snippet image, and a link that opens the document with the passage highlighted.
Reading documents takes a couple of minutes, so the prompt starts the run and collects the result rather than blocking. See [Asking your documents a question](/user-guides/document-evidence-pull) for the full flow.
**Argument:** `months_ahead` (default 6)
Contracts expiring in the next N months, with the vendor risk context attached.
## Monitoring and investigation
**Argument:** `days` (default 7)
Walks new radar alerts and what to do about each.
**Argument:** `vendor_name`
A detailed read of one vendor's risk posture.
**Arguments:** `object_type`, `object_id`
Investigates the audit trail for a single platform object. The answer to "who changed this, and when".
## Reporting
**Argument:** `days` (default 7)
A weekly TPRM executive briefing. The most-used prompt for a Monday standup.
**No arguments.**
An executive risk briefing across the vendor portfolio.
**Argument:** `days` (default 90)
A board-ready program report over a quarter-length window.
## Related
Free-form phrasing for the same workflows, when you don't want to invoke a prompt by name.
The 12 tools these prompts drive, and every route each one covers.
# Security and privacy
Source: https://docs.coverbase.com/mcp/security
Authentication, authorization, data handling, and what we log when you connect the MCP server.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
## Authentication and authorization
The Coverbase MCP server uses OAuth 2.0. We do not store the AI assistant provider's credentials, and the AI assistant provider does not receive your Coverbase password.
Access tokens expire after 24 hours and are renewed with a refresh token. Each refresh re-checks the user's organization membership and issues a new refresh token.
Tool calls run with the connected user's permissions. The connector cannot escalate beyond what that user could do in the Coverbase UI. See [Roles and permissions](/mcp/permissions) for the full model.
The server validates the `Origin` header on incoming MCP requests to prevent DNS rebinding attacks.
All connections use TLS 1.2 or higher with certificates from recognized authorities.
## What we log
When the connector is invoked, we log:
* The OAuth user identity
* The tool called
* The parameters passed
* The timestamp
* The outcome (success or error)
These logs are used for security monitoring, debugging, abuse prevention, and audit. They are retained in line with the retention periods described in our privacy policy.
## What we do not retain
* We do not retain the prompts you send to the AI assistant.
* We do not retain the conversation context the assistant maintains.
* We do not retain the assistant's responses to you.
* We do not collect data outside the scope of the specific tool calls made by the assistant.
* We do not access the assistant's chat history, memory, or files.
The AI assistant provider (for example, Anthropic for Claude) is a separate controller for the prompts you send to it and the responses it generates. Their handling of your data is governed by their own privacy policy.
## Revocation
You can disconnect the connector at any time from the assistant client's connector settings, which removes the tokens that client holds. Coverbase has no separate switch to invalidate an OAuth access token that was already issued: it stays valid until it expires (up to 24 hours). Removing the user from your organization stops the next refresh, and an MCP API key revoked under **Configuration → MCP Server** stops working immediately.
## Write-action protection
Every tool that creates, updates, or deletes data requires an explicit `confirm` parameter set to `true`. The assistant is expected to surface the proposed change in chat before execution. Calls without confirmation return a precondition error rather than executing silently.
## Audit logging
Every tool call is logged with user identity, sanitized parameters, and outcome in Coverbase's security logs. Changes made through the connector run as the connected user and appear in the Coverbase audit trail attributed to that user, alongside actions taken in the dashboard. See [Audit trails](/security/audit-trails) for the full model: what is captured, where to review it, and how to export it.
## Compliance
The Coverbase MCP server is part of our SOC 2 Type II audited platform and inherits the same controls as the core product.
## Vulnerability reporting
Report any security issue to [security@coverbase.ai](mailto:security@coverbase.ai). We acknowledge reports within one business day and follow responsible-disclosure timelines.
See the MCP section of the Coverbase Privacy Policy for full details.
# Tool reference
Source: https://docs.coverbase.com/mcp/tool-reference
Every tool the Coverbase MCP server exposes: the nine read dispatchers and their kinds, the report catalog, the write matrix, and the self-describing capabilities call.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The server exposes **12 tools**. Nine of them are read dispatchers, one per domain, each covering many operations through a `kind` parameter. One returns reports, one performs every write, and one describes the rest.
This shape is deliberate. An assistant handed sixty-five narrowly-named tools spends its context deciding between them and still picks wrong; a dozen tools with explicit routes leave more room for your actual data.
You rarely need this page to *use* the server. Ask for what you want in plain language and the assistant picks the route. This is here for when you want to know exactly what it can reach, audit what an assistant did, or write a prompt that names a specific call.
## Reads
Each read tool takes a `kind` and the identifiers that kind needs. All are read-only and scoped to your organization and your permissions.
### `query_vendors`
Accepted parameters: `kind`, `vendor_id`, `document_id`, `query`, `llm_query_terms`, `run_id`, `document_type`, `document_status`, `service_id`, `uploaded_after`, `uploaded_before`, `limit`.
| `kind` | Returns |
| - | - |
| `search` | Vendors matching a name or filter. |
| `count` | How many vendors you have. |
| `detail` | The consolidated profile: people, assessments, findings, contracts, engagements, obligations, radar alerts, documents. One call. |
| `people` | Contacts on a vendor. |
| `onboarding_status` | Where a vendor sits in onboarding. Takes an ID, not a name. |
| `documents` | Evidence files for a vendor, or org-wide. Narrows on `query`, `document_type`, `document_status`, `service_id`, `uploaded_after`, `uploaded_before`. |
| `document_summary` | A summary of one document. |
| `document_download` | A download link for one document. |
| `document_evidence` | Starts reading the documents themselves to answer a question. Returns a run id, not the answer: a model picks which one or two documents to read (`limit`, default 2, max 5) and reads them. Takes a couple of minutes. |
| `document_evidence_result` | The answer from a started pull, by `run_id`: per document, an answer, a verbatim quote with its page, a confidence, a snippet image, and a link that opens the document highlighted. Omit `run_id` to list recent pulls. |
| `risk_summary` | Risk tier and open finding counts. |
| `financial_health` | The Coverbase Financial Health Score: 0-100 score, risk band, confidence tier, pillar breakdown, financial vitals, peer percentile, adverse events, and the source behind each figure. Never compare scores across confidence tiers. |
| `company_registration` | Validated corporate identity from GLEIF, OpenCorporates, and SEC EDGAR: official name, status, jurisdiction, addresses, and LEI / DUNS / company number / CIK, each with a citation. Prefer this over a web search when a corporate fact is in question. |
| `leadership` | The vendor's [People Intelligence](/products/people-intelligence) dossier: executives, board and key people, who reports to whom, registry filings that name them, and adverse-media and sanctions screening. Separates confirmed names from unconfirmed research candidates. |
| `security_posture` | The outside-in [security posture](/products/security-intelligence) measured against the vendor's own infrastructure: rating and grade, per-factor findings, actively exploited vulnerabilities, and lookalike domains. Requires Advanced company intelligence for your organization. |
| `bill_of_materials` | The currently applied SBOM, AIBOM, HBOM, or SaaSBOM and its components. |
| `bill_of_materials_history` | Every BOM received from this vendor, newest first. |
| `uses_nth_party` | Which of your vendors depend on a named nth-party. |
### `query_assessments`
Accepted parameters: `kind`, `assessment_id`, `eval_id`, `vendor_id`, `status`, `query`, `control_set_id`, `issues_only`, `unresolved_only`, `limit`, `full_text`, `analysis_offset`, `summary_offset`, `recommendation_offset`.
| `kind` | Returns |
| - | - |
| `search` | Assessments by vendor, status, or assignee. Each row carries the outcome and the residual risk, so a whole portfolio maps in one call per page. |
| `zero_touch` | One [Zero Touch](/products/zero-touch-assessments) run: its composite Zero Touch Score, the components behind it, whether the score was applied, and every source cited. |
| `zero_touch_leaderboard` | Vendors ranked by their latest Zero Touch Score, worst first, one row per vendor. |
| `zero_touch_audit` | Every review action on a Zero Touch run (approvals, escalations, corrections to its inputs) and what each did to the score. |
| `detail` | Full assessment: outcome, residual risk, control evaluations, findings with titles, people, documents, and the scope columns (date created, initiated by, run counter, products, services, control sets, parsed control counts). Carries the opening 500 characters of the AI summary as a preview. |
| `summary` | The complete AI-generated summary report: every section the summary prompt produced, plus the recommendation, the residual risk, and any notices. This is the **Summary** column of the Consolidated Assessment Report export. |
| `details_legacy` | The previous detail shape, for compatibility. Carries the outcome and residual risk too. |
| `evals` | Per-control evaluation results. Filterable to issues only or unresolved only. |
| `eval_detail` | One control evaluation in full, including the AI's complete reasoning. |
| `plans` | Assessment plans. |
| `follow_ups` | Follow-ups attached to an assessment. |
Every export column mapped to the call that returns it, with sample input and output.
Reading a long AI analysis: `eval_detail` renders the AI's reasoning whole up to a generous cap. If an analysis is longer than that, the response says so and names the follow-up call that returns the rest: pass `full_text=true` for every section at maximum length, or `analysis_offset` to page through the analysis from a given character. A capped response always announces itself, so a partial analysis is never presented as the complete reasoning.
Reading a long summary report: `summary` works the same way. Pass `full_text=true`, or `summary_offset` (and `recommendation_offset` for the recommendation section), to page through a report longer than one response can carry. The truncation notice names the exact call that returns the next window.
### Risk scores and your scoring settings
Two settings under **Configuration → Scoring** change what every read returns, matching what the Consolidated Assessment Report export drops:
| Setting off | Effect |
| - | - |
| Residual risk tracking | Residual risk is omitted everywhere, level and score alike. A workspace that turns this off does not compute the value, so the stored numbers are whatever the last computation left behind. |
| Numerical scores | Raw inherent and residual risk **numbers** are omitted and the named levels stay. The assessment score percent is a separate column and is unaffected. Vendors are still ranked by inherent risk in the portfolio report, without the score printed. |
### `query_findings`
Accepted parameters: `kind`, `finding_id`, `vendor_id`, `assessment_id`, `commitment_id`, `commitment_status`, `limit`.
| `kind` | Returns |
| - | - |
| `search` | Findings scoped to a vendor or assessment, or org-wide. |
| `detail` | One finding in full. |
| `list_detailed` | Findings with full titles, categories, assignees, due dates, status. Use this rather than `search` when you need titles. |
| `commitments` | Vendor commitments. |
| `commitment_detail` | One commitment in full. |
### `query_engagements_contracts`
Accepted parameters: `kind`, `vendor_id`, `engagement_id`, `contract_id`, `vendor_document_id`, `status`, `status_id`, `limit`.
| `kind` | Returns |
| - | - |
| `engagements` | Engagements, optionally scoped to a vendor. |
| `engagement_detail` | One engagement in full. |
| `contracts` | Contracts by vendor or status. `status_id` filters by one of your custom contract workflow statuses, from `query_platform(kind="statuses", target_type="contract")`. |
| `contract_detail` | One contract in full. |
| `services` | Services on a vendor. |
| `obligations` | Obligations extracted from vendor documents. |
### `query_controls`
Accepted parameters: `kind`, `control_set_id`, `control_id`, `limit`.
| `kind` | Returns |
| - | - |
| `search` | Controls, optionally within one set. |
| `detail` | One control, including its AI evaluation guidance. |
| `control_sets` | Your control sets. |
### `query_questionnaires`
Accepted parameters: `kind`, `questionnaire_id`, `questionnaire_type`, `vendor_id`, `intake_session_id`, `status`, `unanswered_only`, `pending_only`, `offset`, `limit`.
| `kind` | Returns |
| - | - |
| `list` | Your questionnaires. |
| `responses` | Responses to a questionnaire. |
| `intake_sessions` | Intake requests, filterable by status. |
| `intake_review` | One intake session as a reviewer sees it. |
| `intake_questions` | The questions on an intake, with AI drafts and reasoning. `pending_only` is the review queue: unanswered questions plus unconfirmed drafts. |
| `intake_prequalification` | The per-criterion screening verdict and its reasoning. |
| `intake_vendor_matches` | Ranked existing vendors and web alternatives for an intake. |
| `intake_steps` | Which steps this org's intake portal turns on **and off**. Authoritative. |
How these fit together into a complete intake request, and why `intake_steps` is read before anything else runs.
### `query_rfps`
Accepted parameters: `kind`, `rfp_id`, `submission_id`, `query`, `limit`.
| `kind` | Returns |
| - | - |
| `list` | RFPs in the org, newest first. |
| `detail` | One RFP: timeline, rubric, vendors and submissions. |
| `submission_answers` | One submission's answers, each labelled with where it came from. |
| `comparison` | The stored cross-vendor comparison, with its timestamp. |
| `activity` | The RFP's event history, including which AI steps ran. |
The full lifecycle, and what a researched response is and is not.
### `query_radar`
Accepted parameters: `kind`, `vendor_id`, `query`, `llm_query_terms`, `include_common_related_terms`, `limit`.
| `kind` | Returns |
| - | - |
| `detectors` | Radar detectors configured for the org. |
| `alerts` | Alert events, for one vendor or org-wide. |
| `reassessments` | Reassessments, including any started from a radar event. |
| `soc2_nth_party` | Which vendors depend on a named nth-party, searched across SOC 2 reports and custom relationships. Pass `llm_query_terms` with aliases: `AWS`, `Amazon Web Services`, `S3`, `EC2`. |
### `query_platform`
Accepted parameters: `kind`, `object_type`, `object_id`, `target_type`, `target_id`, `query`, `include_inactive`, `limit`.
| `kind` | Returns |
| - | - |
| `notes` | Notes on any object. |
| `audit_trail` | The change history for any supported object. |
| `notifications` | Your notifications. |
| `tags` | Org tags. |
| `statuses` | The status labels defined for a target type. |
| `custom_fields` | The org's custom field definitions: config IDs, types, and the allowed options for select fields. Pass `target_type` to narrow to one object type. |
| `workflows` | Workflow automations. |
| `users` | Users in the org. |
## Reports
`get_report(report_name, ...)` returns cross-cutting aggregations. Each report uses only some of the shared parameters.
| `report_name` | What it returns | Parameters |
| - | - | - |
| `portfolio_risk` | Cross-vendor risk overview. | `top_n` |
| `assessment_metrics` | Completion and throughput over a rolling window. | `days` |
| `evidence_health` | Evidence coverage and gaps. | `vendor_id` |
| `review_queue` | Open findings and in-progress assessments. | n/a |
| `org_activity` | A broad program snapshot in one call. | `days`, `assessment_limit`, `finding_limit`, `radar_limit`, `activity_limit`, `notification_limit` |
| `control_flag_rates` | Controls ranked by how often they flag an issue. The data-driven way to find false-positive-prone controls to tune. | `days`, `top_n`, `min_volume`, `format` |
| `assessment_report` | An executive-ready writeup for one assessment. | `assessment_id` |
| `findings_by_vendor` | Vendors ranked by open finding count. | `top_n` |
| `risk_register` | Risks on your [risk register](/user-guides/risk-register), highest residual first. Every status except closed unless you pass `status` (`proposed`, `open`, `mitigating`, `accepted` or `closed`). | `status`, `domain`, `vendor_id`, `top_n` |
| `risk_simulation` | A what-if scenario over your dependency chain from a plain-English `prompt` (an outage, breach, insolvency, sanction, exit, change, or offboarding). Nothing is saved; the loss estimate is withheld when its inputs are missing. | `prompt` |
`control_flag_rates` accepts `format='csv'` for a spreadsheet-ready export.
## Writes
Every write goes through one tool: `mutate(entity, action, data)`. The per-action parameters go inside `data`.
**Every write requires `confirm: true` inside `data`.** A first call without it returns a confirmation prompt and changes nothing. The assistant is expected to show you the proposed change and wait. See [Roles and permissions](/mcp/permissions#write-protection).
| `entity` | Actions |
| - | - |
| `vendor` | `create`, `update`, `set_tags` |
| `service` | `create`, `update`, `set_tags` |
| `document` | `create`, `update`, `archive` |
| `tag` | `create`, `update` |
| `note` | `add` |
| `finding` | `create`, `update` |
| `obligation` | `create`, `update` |
| `control_set` | `create`, `update` |
| `control` | `create`, `update` |
| `eval` | `update` |
| `assessment` | `start`, `update`, `rerun` |
| `radar_detector` | `create`, `update` |
| `radar_event` | `create` |
| `radar_alert` | `dismiss` |
| `reassessment` | `create`, `update` |
| `custom_field` | `create`, `update`, `set_value` |
| `questionnaire` | `create`, `update` |
| `intake_session` | `create`, `update`, `prequalify`, `suggest_vendors`, `select_vendor`, `upload_document`, `answer`, `submit`, `approve`, `reject`, `request_follow_up`, `archive` |
| `questionnaire_response` | `set_status` |
| `review` | `create`, `update` |
| `contract` | `create`, `update` |
| `engagement` | `create`, `update`, `archive` |
| `rfp` | `draft_brief`, `research_vendors`, `suggest_requirements`, `generate_questions`, `create`, `invite_vendor`, `publish`, `simulate_submissions`, `compare`, `award` |
A few of these carry behaviour worth knowing:
Creating a vendor directly requires `skip_intake: true` in addition to `confirm: true`. Requests to add, buy, or start using a vendor are supposed to go through `intake_session / create` instead, which links or creates the vendor itself. Creating one first leaves a duplicate carrying no due diligence.
The separate flag exists because a generic "yes, create it" is not the same as accepting that due diligence is being skipped.
Editing a control's expectation, evaluation instructions, or evidence requirement changes how the AI judges it. Material edits create a new version rather than overwriting. Pair it with `get_report(report_name="control_flag_rates")` to find the controls worth tuning, and `assessment / rerun` to re-evaluate against the new instructions.
Set `outcome` to `not_an_issue` to clear a false positive, `issue` to flag or reopen one, `mitigated` for a real gap the vendor fixed, or `risk_accepted` for one your organization chose to live with, and attach `review_notes`. Closing an issue does not change the score. This is the per-control correction, distinct from the whole-assessment sign-off in `review / create`.
There is no unarchive.
`draft_brief`, `research_vendors`, `suggest_requirements` and `generate_questions` return proposals and change nothing. `create` is the one write, and it builds the RFP, its rubric, its questionnaire, the vendor records and the invitations in a single transaction. The RFP lands as a draft; no vendor is contacted until `publish`.
A silent RFP researches how each invited vendor would most plausibly answer, from public information. Nobody is contacted, no vendor has agreed to any of it, and every rendering says so. Vendors who already sent a real response are skipped, and a re-run never deletes a real answer.
Setting a value takes a `custom_field_config_id`, and select fields only accept one of their configured option labels. Both come from `query_platform(kind="custom_fields")`.
Writes reject unexpected keys in `data` and return the accepted set. Silently dropping a misspelled `vender_id` would turn a typo into a successful mutation that quietly omits the field you meant to set.
## Discovery
`mcp_capabilities()` takes no arguments and returns a JSON document enumerating every route above with its parameters: name, type, required or optional, and default value.
It's the recommended first call when an assistant isn't sure which route applies, and it's always current, because it's generated from the running server rather than maintained by hand.
## Related
Realistic phrasing for each workflow, and which calls it resolves to.
Twenty scripted workflows you can invoke by name.
How read-only versus read/write is decided, and how it maps to your Coverbase role.
What we log, what we don't retain, and how to revoke access.
# Troubleshooting
Source: https://docs.coverbase.com/mcp/troubleshooting
Common issues when connecting and using the Coverbase MCP server.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
## Connection issues
Confirm your role can connect. Admins, Members, Siloed Members and Guests can; Auxiliary Members and custom roles cannot. See [Roles and permissions](/mcp/permissions#role-to-access-matrix). If only the write tool is missing, the credential is read-only, which is expected for a Guest, a Siloed Member, or a read-only key.
Also confirm the client supports OAuth 2.0 for MCP, not only API-key configurations. Older MCP clients sometimes only support stdio transport, which won't work with the Coverbase server.
The key is almost certainly not reaching the server. A request with no `Authorization` header is answered with `401` and a `WWW-Authenticate` challenge, which every MCP client reads as "start the OAuth flow", so a missing header looks identical to having no key at all.
Check two things:
* Your client config includes `"headers": { "Authorization": "Bearer cb_mcp_..." }`, or `--header` on the command line. A URL on its own is not enough. See [Choosing an authentication method](/mcp/connecting#choosing-an-authentication-method).
* The key starts with `cb_mcp_`. An `ak_` key from **Configuration → API Keys** belongs to the [REST API](/api-reference/api-keys) and is not accepted here; MCP keys come from **Configuration → MCP Server**.
Check that your browser allows pop-ups from the AI client's domain and that you're signed into the correct Coverbase account in the browser session handling the OAuth callback.
If you have multiple Coverbase accounts, sign out of all of them in the browser first, then re-initiate the connection so you're prompted to sign in fresh.
A command-line client such as Claude Code may report an error like:
```text theme={null}
SDK auth failed: HTTP 403: Invalid OAuth error response:
SyntaxError: ... Unrecognized token '<'. Raw body: ... 403 Forbidden ...
```
This happens when something in front of the server returns a raw HTML `403` page where the client expects a JSON OAuth response. The usual cause is a web application firewall that blocks requests with no `User-Agent` header. Command-line MCP clients built on Node send their OAuth and tool requests without one. The Coverbase MCP server explicitly allows header-less requests on the MCP, OAuth, and discovery paths, so on the hosted server this is resolved.
If you still hit it:
* Make sure you added the server with the HTTP transport: `claude mcp add --transport http coverbase https://mcp.coverbase.app/mcp`.
* Update to the latest version of your client and retry.
* If you front the server with your own proxy or firewall, allow requests with a missing `User-Agent` on the `/mcp`, `/oauth/`, and `/.well-known/` paths.
If the error persists, contact [support@coverbase.ai](mailto:support@coverbase.ai) with the client name and version.
## Permission and visibility
The connector enforces your role and permissions. If a record is restricted (for example, an assessment in a restricted folder), it will be invisible to the connector even if you can find it elsewhere in the UI.
Ask your Coverbase admin to confirm the scope of your role.
Search uses partial-name matching but is case-insensitive. Try a shorter query (only the first distinctive word of the vendor name).
If the vendor was recently created or renamed, it may take a few minutes to index. Try again after a short wait.
## Write actions
Every write tool requires `confirm=true`. If the assistant is calling the tool without confirmation, the call returns a precondition error rather than executing silently.
Re-issue the request and approve when the assistant proposes the change. If the assistant isn't surfacing a confirmation step, that's a client behavior issue; report it to your client vendor.
Refresh the affected record in the Coverbase UI. Some object types cache briefly.
Check the audit trail for the record (Vendor → Activity, Assessment → Activity, etc.) to confirm the write was applied. If the audit trail shows the action but the UI doesn't reflect it, report it to support.
## Rate limits and performance
The MCP server sits behind the same request-rate limits as the Coverbase API, counted for each combination of credential and IP address over a one-minute window. A client over the limit gets `403` responses until the window passes, so slow down and retry after a minute.
For production use cases that require higher throughput, contact your account manager.
Some routes (notably `get_report(report_name="org_activity")` and `query_vendors(kind="detail")`) consolidate many internal calls into one to save tokens, which can be slower on accounts with very large data volumes. Try narrower scoping (specific vendor ID, shorter time window).
## Other
Try removing and re-adding the connector. If the issue persists, contact [support@coverbase.ai](mailto:support@coverbase.ai) with a screenshot.
If it speaks MCP with OAuth 2.0 and Streamable HTTP transport, it should work. Let us know what you're using and we'll add it to the test matrix: [support@coverbase.ai](mailto:support@coverbase.ai).
## Status and updates
status.coverbase.com
Tool additions, parameter changes, and deprecations with at least 30 days notice for breaking changes.
## Contact
[support@coverbase.ai](mailto:support@coverbase.ai)
[security@coverbase.ai](mailto:security@coverbase.ai)
[privacy@coverbase.ai](mailto:privacy@coverbase.ai)
# Vendor intake in chat
Source: https://docs.coverbase.com/mcp/vendor-intake
File a complete vendor intake request through an AI assistant: identity confirmation, alternatives, pre-qualification, and the inherent risk questionnaire, without opening the portal.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The vendor intake request a requester normally fills in through the browser portal can be run end to end in conversation. The assistant opens the request, researches the vendor, confirms you have the right company, shows you what you already own that might do the job, runs the screening your org configured, walks the inherent risk questionnaire with you, and submits it to your review queue.
The result is the same intake session (`cbintksn_...`) the portal produces. It lands in the same **Intake** queue, carries the same questionnaire answers, and waits on the same reviewer.
Intake is one of three ways into the same process. The [Intake API](/api-reference/intake) is for embedding intake in another system, the portal is for a requester at a browser, and this page is for chat. All three produce the same session and the same review.
## Starting one
You don't need to know the word "intake". The assistant recognizes the intent from ordinary phrasing:
* "I want to add a new vendor, Marqeta."
* "I want to start using Northwind Analytics."
* "We're onboarding Datadog."
* "Can we buy this? My team needs it for load testing."
* "Run due diligence on Acme."
* "Is Acme approved?"
That last one resolves first: the assistant looks the vendor up, and if there's no approved record, offers to start the intake rather than answering "no" and stopping.
**A new vendor request never becomes a bare vendor record.** Creating a vendor directly would leave a row in your registry with no due diligence attached to it, and a duplicate to clean up later. The assistant routes these to intake instead. If you genuinely want a record with no diligence, say so explicitly, and the assistant will tell you what you're giving up before it creates one.
## What the assistant does
From the vendor name alone. You are not interrogated for a use case first, because the assistant can offer you real choices once it has researched the vendor. If the name matches vendors you already have, it shows you the candidates and asks which one, rather than guessing or silently creating a new vendor.
Before running anything. Your intake portal decides which steps exist, and the assistant reads that first so a step your org turned off is never run in the first place. See [Your configuration is the script](#your-configuration-is-the-script).
What the company does, its website, its headquarters location, its trust center, and the match confidence. You get that profile and confirm it's the right company before anything else happens. Two vendors called Acme is the ordinary case, not the edge case, and a request filed against the wrong one wastes a full review cycle.
Existing vendors in your portfolio that do the same job, prior relationships with this vendor, and alternatives found on the web, to the extent your portal enables each. If something already approved covers this, you're told before you commit, not after the request is filed. Catching the duplicate purchase is what intake is for.
Not as blank questions. You get a numbered list of what this vendor is bought for, drawn from the research, and another of the candidate services in scope. Every menu takes an answer that isn't on it, so you're never forced into a choice that doesn't fit.
Pre-qualification (financial stability, security posture, sanctions) and the duplicate check run as part of the flow, and the assistant reports what came back. It still asks your go-ahead before each write. The difference is that it tells you what happens next instead of asking whether to bother. Only a *failed* screen is handed back to you as a decision.
Coverbase's AI answers what it can from the context you gave and public sources, the same background process the web intake uses. This takes a moment; the assistant waits for it.
Each drafted answer arrives marked **AI draft, needs confirmation**, with the reasoning behind it. You accept, correct, or replace it. The questionnaire is not optional and the assistant won't offer to skip it; if you stop partway, it tells you the request stays incomplete.
Which fails if a required question is still unanswered, and moves the request to pending review.
## Submitting is not approval
Filing an intake request is not permission to buy, sign, or deploy anything.
At the end of the flow a vendor record may exist in Coverbase, but it sits in **Created** status. It is not an approved vendor. Your security or due diligence team reviews the submitted request and decides it, and only that decision authorizes use.
A well-behaved assistant says this explicitly when it closes out the flow rather than leaving you to infer it from a green checkmark. If yours ends an intake in a way that reads like approval, that's worth reporting to us.
## Your configuration is the script
The steps above are not hardcoded. Your organization's intake portal decides which of them exist, and the assistant reads that configuration before it runs anything.
| Portal ask | What it enables in chat |
| - | - |
| **Vendor search** | Vendor matching, existing-vendor alternatives, web alternatives, and prior assessment history. Each is separately switchable. |
| **Prequalification** | Financial, security, and sanctions screening. Each check is separately switchable. |
| **Questionnaire** | The inherent risk questionnaire attached to the intake. |
| **Document upload** | Attaching supporting evidence to the request. |
An ask you removed means the step is off, and the assistant will not reintroduce it in conversation. If your org turned off web alternatives, or prior assessment history, or pre-qualification, chat honours that. This matters because a chat interface is otherwise easy to talk into doing extra work you deliberately disabled.
If the assistant runs a step you don't expect, ask it what your portal configuration reports. It can read the enabled and disabled steps back to you directly.
## Every write asks first
Opening the request, recording an answer, running pre-qualification, and submitting are all writes, and every one of them requires your explicit approval before it executes. The assistant proposes the change in chat and waits.
This is the same human-in-the-loop rule that applies to [every write tool](/mcp/overview) on the MCP server. Intake is not exempt from it, and the guided flow doesn't turn into an autonomous one.
## What still needs the app
Two question types have no sensible chat representation and report themselves as app-only:
* **Contact questions**, whose answer is a structured person record.
* **Document-upload question types**, which need a file picker.
The assistant gives you a deep link to finish those in Coverbase. Everything else completes in the conversation.
## Reviewing what comes in
The other half of intake is the reviewer's, and it also runs in chat. The assistant can walk your pending-review queue, summarize each submission with its enrichment and screening results, and approve, reject, or request follow-up, each with confirmation.
Reviewers who prefer the dashboard lose nothing: sessions filed through chat appear in the **Intake** queue exactly as portal submissions do.
## Prompts
The server ships canned prompts that script these flows, so you can invoke one instead of describing what you want:
| Prompt | What it does |
| - | - |
| `submit_intake_request` | Files a new vendor intake request end to end. |
| `triage_intake_queue` | Walks every pending-review intake session. |
| `review_intake` | Approves, rejects, or requests follow-up on one session. |
| `onboard_new_vendor` | Adds a bare vendor record with no due diligence. Only when you explicitly want to skip intake. |
Realistic phrasing for each of these, and what the assistant does with it.
## Related
The REST path: create sessions programmatically and poll for generated answers. For embedding intake in procurement or ticketing.
The product: classification, assessment plan selection, and downstream workflow orchestration.
Set up Claude, Cursor, VS Code, or any MCP client against the Coverbase server.
What the connected assistant can see and do, and how that maps to your Coverbase role.
# Agent Ledger and AI governance
Source: https://docs.coverbase.com/products/agent-ledger
A record of every action an AI agent takes on your data, the policies that say what agents may do without a person, personal data redaction before model calls, and calibration from your own reviewers' corrections.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Your Coverbase representative turns on the third-party lifecycle features, including the Agent Ledger, for your organization.
The **Agent Ledger** page under **Configuration** answers the questions an auditor, a model risk team or a regulator asks about AI in your program: what did an agent do, to which record, based on what, how sure was it, which models did it call, and what did a person decide. Beside the ledger sit your organization's AI settings.
![Agent Ledger page listing actions by the evidence, monitoring, radar and intake agents with confidence scores and decisions such as Accepted, Applied under org policy and Awaiting review, beside the agent policy switches and the Privacy panel]()
## What it does
Which agent, what it did, to which record, what it read, what it cited, its confidence, the models it called and how many personal details were redacted. A person can accept, edit and accept, or reject an action, one at a time or in bulk.
What agents may do without a person, enforced where the agent acts. Re-timing monitoring from feed signals (off by default) and proposing diligence reuse (on by default) are live. Accepting risk or closing an issue always needs a person and cannot be switched on.
Off by default. When on, email addresses, phone numbers, IBANs, US tax IDs and the names of your users and your vendors' contacts are replaced with placeholders before a request reaches the model, and put back in the answer before anyone sees it.
When a reviewer overturns a control evaluation, the correction becomes an example for that control. Nothing reaches an evaluation until you turn learning on, and you can switch any example off.
**Export for audit** writes the actions matching your filters, up to 50,000, to a CSV in the background, with citations, models, the redaction count and the human decision.
## What is recorded today
These agents write to the ledger: control evaluation, vendor matching and question planning during intake, follow-up suggestions, the [Intake Agent](/products/intake-agent) reading a request from a message, questionnaire drafting in the portal, document analysis, the Zero Touch automated review, contract clause review, [claim checks](/products/claim-check), the risk report narrative, and Radar signal summaries.
## Agent policies
A policy is checked where the agent acts, against the current setting, so a policy switched off a moment ago holds.
| Policy | What the agent does | With the policy off |
| - | - | - |
| **Re-time monitoring from feed signals** (off by default) | Moves monitoring plan activities forward when a Radar alert or reassessment trigger fires. Each moved plan gets a row reading **Applied under org policy**. | Nothing moves. One row per vendor and signal reads **Held back by org policy**. |
| **Propose diligence reuse** (on by default) | Picks the similar engagement inside the reuse window that the Front Door starts reviewers from. Recording the disposition writes a row with the reviewer's acceptance or rejection. | No proposal. Reviewers start from full due diligence and still see every match. |
**Auto-close low tier reassessments with no changes** and **Send anything to a vendor without review** have no agent behind them yet, so they stay off and cannot be switched on. **Accept risk or close an issue** always needs a person.
Writing a ledger row never fails the action it records. A failed action is recorded as **Failed**.
## How redaction works
Redaction runs in the connection to the model provider, not in individual features, so every model call your organization makes passes through it. If Coverbase cannot read whether redaction is on for your organization, the call fails rather than going out unredacted. Placeholders look like `[[PERSON:1a2b3c4d5e6f]]`. Each is a keyed hash under a secret held for your organization, so the same person gets the same placeholder across calls and a placeholder cannot be reversed by guessing. Only placeholders the redactor issued are restored.
Redaction covers the text of a request. It does not reach inside images or attached documents, such as a PDF sent to the model as a document, or a file the model provider reads directly from storage. Bank and tax identifiers stored on supplier records are sealed per field and never reach a prompt in clear, whether or not redaction is on.
A model request type that redaction does not cover fails while redaction is on, so a new kind of call cannot bypass it.
## How learning works
A daily job collects every evaluation a reviewer moved across the issue boundary in the last 180 days, in either direction, as a learned example for that control. With learning on, a control's evaluation gets up to five of its enabled examples and your organization's evaluation guidance, marked as reference data. With learning off, evaluations use the baseline prompt unchanged. Learning applies to your organization only.
## Where to go next
Read the ledger, record a decision, set policies, turn on redaction and learning, and export.
How Coverbase selects, tests and constrains the models behind these agents.
How assistants connected through MCP are logged and constrained.
Encryption, field-level sealing and tenant isolation.
# Agentic Inspect
Source: https://docs.coverbase.com/products/agentic-inspect
Agentic, browser-based vendor inspection that converts attestations into verified control evidence.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Inspect performs structured discovery using a headless browser. It works against two surfaces: a **vendor's** public and authenticated surface area, where it validates attestations and extracts evidence from trust centers; and **your own application tenants**, where it signs in and reads the live admin console to collect evidence for a chosen set of controls. Either way it captures screenshots and artifacts with full chain-of-custody metadata.
## What it does
Parse vendor trust centers (Drata, Vanta, SafeBase, custom portals) to extract published controls, certifications, and evidence references.
Convert claims into verified evidence by retrieving the vendor's published attestation pages and audit reports directly.
Record screenshots, source URLs, timestamps, and request metadata for every artifact so audit trails are defensible.
Sign in through Okta or Microsoft Entra SSO, a Google account, or a username and password, answering one-time codes and passkey prompts, so Inspect can reach evidence behind a login. For a gated vendor trust center, the agent fills in the access request form.
## Inspecting your own applications
The other half of Inspect points at the applications *you* run. Rather than asking a vendor whether MFA is enforced, Inspect signs in to the tenant and reads the answer off the admin console.
An **inspection** is one request against one target, with one control set and one purpose. Inside it, each control gets its own **control run**, so one control failing to collect evidence never stops the rest.
Establish whether the evidence a control needs can be collected from this application at all. Run this first against an unfamiliar tenant.
Adjudicate the evidence against the control expectation and your scale. This is the run that produces a judgment.
Compare against a compatible earlier inspection, so a setting an administrator changed since the last run surfaces as a difference.
Control sets come from the [Internal Controls Library](/control-library#internal-controls-library): 22 templates spanning 392 controls, covering identity, privileged access, integrations and OAuth, data handling, PII, PHI, GDPR, AI features and agents, resilience, SLA conformance, audit logging, and licensing, plus a CIS Controls v8.1 SaaS baseline.
Re-run on a cadence and **Drift** turns point-in-time evidence into continuous assurance: each comparison reports `exact`, `changed`, or an explicit reason it could not be compared, and a change is judged material, immaterial or inconclusive with a summary of what differs. A material change sends an alert to whoever requested the inspection, and an issue an Evaluate run raises becomes a finding, on the same Findings page as everything else, when you create one from it. See [Internal control monitoring](/products/internal-controls-monitoring) for how that joins up with third-party risk.
**Absent evidence is reported, never omitted.** An observation that could not be obtained still exists and still says why: unsupported, authentication required, forbidden, inconclusive, or failed. An application that does not sell a capability is not marked down for lacking it.
Progress and outcome are separate facts. "5 of 5 controls finished" says nothing about whether any of them passed, so read the status rather than the count.
## How to integrate
Inspect accepts inspection plans and returns structured findings suitable for ingestion into an assessment record.
Specify target domains, evidence types, and auth context for each plan.
Results return as structured records that map directly to Coverbase evaluations, with citations and captured artifacts attached.
## Common workflows
Instead of emailing a vendor for proof of encryption at rest, Inspect pulls the relevant section from their SOC 2 in the trust center, captures it with chain-of-custody metadata, and attaches it to the evaluation.
When a reassessment collects documents automatically, the agent retrieves the vendor's trust center documents again, so an updated SOC 2 or a lapsed certification is what the new evaluation reads.
Retrieve the vendor's trust center documents before sending a questionnaire. Controls the documents already answer are evaluated from them, and follow-up questions go to the vendor only for the gaps.
## Related
Running Inspect against your own applications, and how internal and third-party risk share one model.
The internal and vendor control sets Inspect evaluates against.
# Assessment Copilot
Source: https://docs.coverbase.com/products/assessment-copilot
AI-powered assessment engine that automates approximately 90% of vendor risk assessment workload.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Assessment Copilot replaces manual, spreadsheet-driven workflows with a programmatic pipeline. It generates custom questionnaires, extracts controls from uploaded evidence, evaluates vendor responses, and drafts follow-ups for the gaps, routing the cases the evidence cannot settle to human reviewers.
## What it does
Generate vendor questionnaires scoped to the control sets you care about, the vendor's risk tier, and the services in scope.
Parse SOC 2 reports, ISO certifications, pen test summaries, and policy documents to extract control evidence automatically.
Evaluate every control against the vendor's answers and documents, flagging weaknesses as issues and marking what the evidence cannot settle for review rather than guessing.
Draft targeted follow-up questionnaires from the issues an assessment raises, flag residual risk for reviewer attention, and schedule the next reassessment from the vendor's risk level.
## Evidence quality controls
Copilot researches the public web when a control can't be answered from the documents on file. That evidence is not taken on trust: every candidate page is graded for **publisher accountability** (Unreliable, Reputable, or Authoritative), and anything below the minimum you configured is discarded before the evaluating model sees it. Accepted citations carry their grade, the reason for it, and the page's age at the time it was cited, both in the UI and in the Excel export.
The full guide: the grading scale, where to set the minimum per control set or per control, how the bar is enforced, and what it does and doesn't cover.
## How to integrate
Copilot is exposed across both API surfaces:
Pull assessment results, evaluations, and findings into your compliance dashboards or regulatory reporting pipeline.
Drive assessments from a conversational interface. Start a new assessment, summarize results, or find controls that need human review.
## Common workflows
Wire Copilot into your vendor onboarding flow. When a new vendor enters intake, trigger a Copilot assessment scoped to the appropriate control set and tier. Pull results via Export API and surface them in your procurement system before contract execution.
Schedule reassessments on a recurring cadence for each risk level (annual, semi-annual, or any interval), or trigger one from an event such as a Radar alert or a jump in the vendor's risk score. Each reassessment evaluates the controls again against the latest evidence.
Set each control set's strictness to decide how much the evaluation may infer on the vendor's behalf, and route assessments to named reviewers for approval. An evaluation the evidence cannot settle is marked for review rather than guessed, and issues surface for a person to accept, dismiss or follow up.
Copilot is part of the Coverbase platform and is accessed through the Export API and MCP server rather than a dedicated endpoint. See the [Export API Concepts](/export-api-concepts) page for assessment and evaluation base objects.
# Autonomous Intake
Source: https://docs.coverbase.com/products/autonomous-intake
Vendor intake that researches the vendor, catches duplicate spend, screens it, and drafts the risk questionnaire, then routes every request into the TPRM program at the correct depth.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Autonomous Intake removes the manual routing layer between procurement and risk teams. A requester says what they want; Coverbase identifies the vendor, checks whether you already pay for something that does the job, screens the company, drafts the inherent risk questionnaire, and puts a complete request in front of a reviewer. Every engagement enters the TPRM program at the correct depth, and the requester spends minutes rather than an afternoon.
## What it does
Accept submissions in their natural form (requester context, vendor identity, intended use, data types) without forcing a rigid form structure.
Identify the company from a name: what it does, its website, its headquarters, its trust center. The requester confirms the match before anything else runs, so a request is never filed against the wrong Acme.
Rank your existing vendors against the request and surface prior relationships, so a second tool for a job an approved vendor already covers gets caught before the spend, not during review.
Screen financial stability, security posture, and sanctions exposure as part of the flow. Screening can be turned off per intake portal, and a vendor that doesn't clear is surfaced to a human rather than auto-rejected.
Answer the inherent risk questionnaire from public sources and the context supplied, with per-answer confidence and the reasoning behind each. The requester validates rather than types.
Score each request's inherent risk from the questionnaire answers (data sensitivity, criticality, engagement type) and band it on your risk scale, overall and per risk domain. Drives which controls apply.
When a reviewer approves the request and launches an assessment, the assessment plan's rules pick the control sets from the inherent risk score, the per-domain scores, and tags, including any custom control sets layered on your baseline standard.
Trigger workflow automations when a request is submitted or approved, so the assessment, the contract, and downstream tickets follow without a manual hand-off.
## Three ways in, one process
A request can arrive three ways. All three produce the same intake session, obey the same configuration, and land in the same reviewer queue.
A requester fills in the browser form: select vendor, add information, review questionnaires.
`POST` a free-form payload from procurement or ticketing and poll for the generated answers.
An AI assistant runs the whole request conversationally through the MCP server.
## You decide which steps run
Intake is configuration, not a fixed script. Your intake portal decides which steps exist, and every surface honours it, including chat, which will not reintroduce a step you deliberately turned off.
| Step | What you control |
| - | - |
| Vendor search | Matching against your existing vendors, web alternatives, and prior assessment history, each separately switchable. |
| Pre-qualification | Whether financial, security, and sanctions screening runs, and whether sanctions are checked with [Coverbase sanctions screening](/user-guides/sanctions-screening#screen-a-vendor-at-intake) or the OFAC list. |
| Questionnaire | Which questionnaires attach to the intake. |
| Document upload | Whether supporting evidence is collected at intake. |
## Submitting is not approval
A completed intake request is a request, not permission. A vendor record created through intake sits in **Created** status; it is not an approved vendor until a reviewer decides the request.
This is the point of the product. The requester gets a fast, guided path and a clear answer about what happens next; the risk team keeps the decision.
## Common workflows
A requester asks an AI assistant for the tool they want ("I want to start using Northwind Analytics"), and the assistant runs the request: confirms the vendor's identity against research, surfaces existing vendors that already cover the need, runs the screening the portal configures, and walks the inherent risk questionnaire one question at a time. No form, and no requester who has to learn the word "intake". See [Vendor intake in chat](/mcp/vendor-intake).
Call the [Intake API](/api-reference/intake) from your procurement or ticketing system. When a requester opens a new vendor request there, the request's free-form context becomes an intake session, and Intake researches the vendor and drafts the questionnaire before a reviewer sees it.
Use the classification to drive approval routing. Tier 1 vendors loop in CISO and Legal; Tier 4 SaaS tools follow a lightweight path. The same intake form, different downstream depth.
Let requesters submit through a simple form. Intake handles classification, reviewer assignment, and follow-up questions to the requester so risk teams aren't the bottleneck.
Requests arrive pre-enriched with the screening results, the duplicate readout, and the auto-answered questionnaire. Reviewers validate rather than research, and can approve, reject, or send a request back with a specific question. This works in the dashboard or in chat.
## Guides
For the business requester: what you'll be asked, how to file it, and what happens after you submit.
For the risk team: triaging the queue, reading the enrichment, and validating auto-answered questions.
Autonomous Intake is configured in the dashboard and exposed programmatically through the platform API. See the [Intake API reference](/api-reference/intake) for creating intake requests with free-form context. Talk to your account manager about API access if it's not yet enabled on your plan.
# Certificate Vault and prequalification
Source: https://docs.coverbase.com/products/certificate-vault
One repository for every certificate a vendor holds, whether uploaded, read from a document, pulled from ISNetworld, Avetta or EcoVadis, or found in a trust center, with prequalification rules that can block new purchase orders and licensed security, financial and credit ratings in Radar.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Your Coverbase representative turns on the third-party lifecycle features, including the Certificate Vault, prequalification, and the licensed rating connectors with their Radar rating detector, for your organization.
The Certificate Vault is a record for every attestation your program relies on: ISO certificates, SOC reports, PCI attestations, certificates of insurance, network grades and ESG ratings. Prequalification rules read the vault to decide which vendors may be used, and licensed rating providers feed rating changes into Radar.
## What it does
**Certificates** in the left navigation lists every certificate across your vendors, and each vendor has a **Certificates** tab. Validity (valid, expiring within 60 days, expired) is worked out when you look, so it never goes stale.
Certification, PCI, SOC 1 and SOC 2, ACORD 25 and insurance policy documents fill the vault when they are analyzed. Trust center documents, network pulls and certificates you add by hand fill it too, and you can request a certificate from the vendor through the supplier portal.
Rules that must all pass, each passing when any one of its conditions does: a network grade, a network status, a certificate held, insurance coverage with a minimum limit and additional insured, or a safety or ESG figure such as TRIR, EMR, DART rate or ESG score.
A rule set can block new purchase orders until the vendor qualifies or someone records an override with a rationale. An override lapses when the result changes.
ISNetworld and Avetta grades, safety statistics and insurance, and EcoVadis scorecards, sync into the vault daily.
Bitsight, SecurityScorecard, RapidRatings and Moody's ratings are pulled for your portfolio. A change in a matched vendor's rating becomes a Radar signal, and the first pull is a baseline, so connecting a provider does not flood Radar.
![Certificates page with counts for certificates, expiring in 60 days, expired and from networks, the All Certificates table, two prequalification rule sets and the Networks card]()
When a provider's response does not have the shape Coverbase expects, the pull stops and records the error rather than reading it as empty, so a changed response never archives certificates. A value the provider reports as zero, such as a rating, a score, an insurance limit or a company ID, is recorded as zero.
## How long a certificate counts
* A SOC report is relied on for a year past the end of its period.
* A certificate of insurance is only as current as its first policy to lapse.
* Every prequalification condition reads only current certificates, so an expired record stops counting for its grade and its figures alike.
* A safety figure over a number of years needs each of the latest years reported. A missing year fails the condition.
## Where prequalification shows up
* On the vendor's page, as **Qualified**, **Blocked** or **Overridden**, with **Override with rationale**.
* On the Front Door review of an intake request, with the same override control.
* When someone issues a purchase order in Coverbase for a blocked vendor: the purchase order is refused.
* In workflows, as a prequalification condition you can branch on.
A failing rule set that does not block reads as advisory. Results are recalculated when a certificate changes, when you save a rule set, and once a day. Each rule set can remind relationship owners a set number of days before a certificate lapses.
## Where to go next
Fill the vault, write a rule set, override a result and connect a network.
Connect contractor grades, statistics and insurance.
Bring security rating changes into Radar.
Where rating changes become signals.
# Claim check
Source: https://docs.coverbase.com/products/claim-check
Test each vendor questionnaire answer against the evidence the vendor already gave you: SOC reports, certifications, trust center documents, the outside-in scan, licensed ratings and contract terms. Every verdict cites the passage it rests on.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
A vendor's questionnaire answer is a claim. Claim check reads the evidence you already hold on that vendor and says, for each answer, whether the evidence supports it, contradicts it, cannot settle it, or says nothing about it. It runs in the background on a questionnaire submission and appears on the submission's **Claim Check** tab.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
![Claim Check table filtered by verdict, listing five answers marked Contradicted, Needs evidence, Not covered with Answer changed, and Supported, each with a confidence score and the number of passages cited]()
## The four verdicts
| Verdict | Meaning |
| - | - |
| **Supported** | The evidence on file establishes what the answer claims. |
| **Contradicted** | The evidence on file says something the answer cannot be true alongside, such as an exception the auditor noted. |
| **Needs evidence** | The evidence speaks to the topic, but neither proves nor disproves the answer. |
| **Not covered** | Nothing on file speaks to the answer. |
Every verdict except **Not covered** carries the passages it rests on, with the source, the page and the quoted text highlighted.
## How a verdict is reached
* **The model proposes, code decides.** A model reads each answer with the most relevant evidence (between four and ten items) and proposes a verdict with quotes. Code then checks every quote against the source text. A quote that cannot be found in the source is dropped, and a **Supported** or **Contradicted** verdict with no quote left falls to **Needs evidence**, with its confidence capped.
* **Authority comes from the kind of evidence, not the model.** Auditor's reports, accredited certifications, independent assessments, the outside-in scan, licensed ratings and executed contract terms are **Authoritative sources**. Vendor policies, trust center pages and draft contract terms are **Vendor's own statement**. An authoritative contradiction outweighs a vendor's own statement that agrees, so a trust center page cannot clear a SOC 2 exception.
* **One verdict per answer.** Checking again replaces the verdict. When an answer changes after it was checked, the verdict shows **Answer changed** until it is checked again.
* **Recorded in the Agent Ledger.** Every model call is a ledger row, with personal data redaction applied when your organization has it on.
## What you can do with a verdict
* **Raise finding with this evidence**: one finding per question, narrowed to the question and carrying the answer, the verdict and the cited evidence. Answers that already have an open finding are skipped.
* **Ask vendor to clarify**: a message on the vendor's portal request, attached to the question. The vendor sees which question a message is about only when their own form on that request asks it.
* **Check again** on selected answers.
Each bulk action reports what it did and what it left alone, for example "3 findings raised, 1 already had a finding".
## Where to go next
Run a check, read the verdicts and act on them.
The rest of the due diligence workbench.
How source credibility is graded.
Where each check is recorded.
# Clause packs and non-standard contracts
Source: https://docs.coverbase.com/products/clause-pack
Turn an engagement's risk results into the contract clauses it requires, see whether the draft carries each one, monitor the obligations in the signed contract, and list every non-standard clause across your contracts.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
A clause pack turns an engagement's due diligence results into the contract clauses that hold the vendor to controlling the risk. Your legal team maps clauses to risk domains once. For each engagement, Coverbase then lists the clauses its risk results and open issues require, shows whether the current draft carries each one, and, once the contract is signed, turns the obligations those clauses carry into activities on the engagement's monitoring plan.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
![Clause Pack from the Risk Results listing required clauses such as Audit rights and Encryption at rest, the risk domain and level or open issue that requires each, and whether each is not reviewed or added to the redline]()
## What it does
On a reference clause in **Clause Sets**, **Required by Risk Domain** names the risk domain and minimum level that require it, optionally also whenever the domain has an open issue, and what to monitor after signing.
The engagement's **Contract** tab lists each required clause, why it is required (for example **Privacy · High** or **Open issue**), and whether the draft has it: **Present**, **Missing**, **Non-standard**, **Added to redline** or **Not reviewed**.
An open issue with a remediation due date adds a covenant to the pack, so the contract holds the vendor to the fix.
When the contract is signed, each required clause that made it into the contract and carries an obligation becomes an evidence request or scorecard activity on the monitoring plan, on its cadence. Event obligations are watched through Radar and issues instead.
Every clause whose latest review found it non-conforming, missing or needing review, across all contracts, filterable by severity, status and risk domain, and exportable as CSV.
![Non-standard Contracts report with search, severity, status and risk domain filters, Export CSV, and seven clauses marked Missing, Non-conforming or Needs review]()
## The rules it follows
* **The pack reads what the Risk Summary reads.** It uses the same domain results (residual where there is one) and the same open issues, so the pack cannot disagree with the decision it follows.
* **Clause review decides what the draft says.** The draft state comes from the latest complete [Contract Guardian](/products/contract-guardian) review of each contract linked to the engagement. The pack only marks a clause for the redline.
* **Rebuilding never drops a signed obligation.** A clause no longer required leaves the pack, unless it is already in the signed contract.
* **Only signed clauses are monitored.** At signature, a clause the draft held or that was added to the redline counts as signed. One still missing or non-standard does not, and its obligation is not monitored.
## Where to go next
Map clauses to risk domains, build a pack and read the report.
The clause review the draft state comes from.
Where signed obligations are monitored.
The Risk Summary the pack follows.
# Contract Guardian
Source: https://docs.coverbase.com/products/contract-guardian
Contract analysis, clause review, and redline surfacing for third-party agreements.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Contract Guardian extracts clauses, detects missing clauses, analyzes liability and indemnity, surfaces AI-usage provisions, and flags deviations from an organization-defined playbook. Rerun it against amendments and addenda so the contractual control surface stays aligned with the live risk profile maintained in Supplier Radar.
The core idea: you write down your standard once, as tiers of acceptable language. Coverbase then finds the vendor's version of each clause, decides which tier it lands in, and gives your reviewer a short list of deviations with the source text quoted and highlighted, instead of an agreement to read end to end.
Guardian decides which clauses deviate and how far, then marks the asks up for you. It does not negotiate. A person reviews the marked-up file and decides what to send.
## What it does
Parse MSAs, DPAs, SOWs, BAAs, and order forms to extract clauses, terms, and obligations into structured records.
Compare extracted contracts against your playbook and flag clauses that should be present but aren't (data breach notification, audit rights, subprocessor flow-down).
Surface liability caps, indemnification scope, and limitation-of-liability language so legal teams can focus review on what deviates from standard.
Detect AI-specific clauses, model training restrictions, output ownership, customer data usage in model improvement, and flag where they're missing.
## Clause sets and risk tiers
A **clause set** is your playbook. Each **reference clause** in it is one standard you hold vendors to, carrying a severity, guidance that tells the matcher how to find the clause, the contract components it applies to, and a set of **variants**: versions of the clause language at different levels of acceptability, tiered 1 to 5.
Coverbase matches the vendor's actual language to the closest variant, and the tier drives the verdict:
| Risk tier | Meaning | Clause state |
| - | - | - |
| 1-2 | Preferred or acceptable | **Conforming** |
| 3 | Negotiable, warrants a look | **Needs review** |
| 4-5 | Materially worse, or unacceptable | **Non-conforming** |
Sets copied from the packaged library are scored against a target tier instead, so a vendor meeting or beating the ask conforms. Two guardrails sit on top: a low-confidence match is escalated to **Needs review** rather than auto-passing, and language found outside the components a clause was scoped to is escalated the same way. Where no language is found, the result is **Missing** when the relevant component is present in the contract, and **Not applicable** when it isn't.
### Three ways to build one
Copy one of 12 packaged templates, from Enterprise SaaS to HIPAA to Payments: 311 reference clauses between them, each with four tiers of language already written. Your copy is fully editable.
Upload your template MSA or DPA as a baseline contract, or your negotiation playbook with its preferred and fallback positions. Guardian builds the clause set from the exact language in your document. A playbook kept in a spreadsheet imports directly.
Author reference clauses directly for narrow, high-stakes standards. Clauses are versioned, so edits never rewrite the history of reviews already run.
## Review and triage
Guardian first detects the logical components inside the linked documents (MSA, DPA, order form, SLA, NDA, SCCs, AI addendum, amendments), then evaluates each reference clause only where it belongs.
Each result carries the extracted vendor language, the matched variant, a confidence score, the source document and page, and highlighted evidence in the PDF.
Where the vendor has a completed assessment, flagged clauses are cross-referenced against that evidence and given a suggested disposition (no action, revise language, add clause, or escalate) with citations back into the assessment.
Reviewers mark each flag as no action, accepted risk, or false positive, or escalate it to a tracked finding. The system verdict and the human decision are both preserved on the record.
Select the deviations worth pushing back on and generate an outbound follow-up draft built from those specific clauses. Nothing sends automatically: copy it, open it in the email composer addressed to the vendor with the redline attached, or escalate to a finding.
Where the contract arrived as a Word file, download it back with the vendor's wording struck and your playbook's inserted as tracked changes, plus a comment per clause carrying the ask. It opens in the Review ribbon the vendor already uses.
## Draft versioning and redline history
A contract is a family of documents, not a file, and Guardian is built on that model. Drafts, redlines, executed originals, amendments, restatements and exhibits are all held together and ordered, so "what did we agree, and how did we get here" is answerable without opening six PDFs.
Coverbase draws a typed relationship between any two documents in a family: **amends**, **restates**, **attaches to**, **redline of**, and **duplicate of**, each recorded with the evidence that produced it. A version chain is data, not a naming convention.
A marked-up draft is detected from its tracked changes and its content, and routed to the **redline and negotiation history** component. It is kept for the record, and it is **never in force**: an unsigned Net 45 draft can never compete with the signed Net 60 amendment for the payment-terms slot.
Amendments resolve as an ordered series where each supersedes the last, with the effective date deciding. A superseded instance stays visible in the history rather than being deleted, and anything contributing nothing in force, a redline or a duplicate, renders struck through.
Each resolved term names the document, the page and the effective date it came from: "Net 60, from Amendment 3 effective 1 Jan 2024, supersedes Net 30 in the master agreement." You can open the source span from the answer.
Two further version-history properties matter for legal review:
* **Conformed copies are handled deliberately.** A master re-issued with its amendments already incorporated is recognized as such, and you choose whether the absorbed amendments stay as separate terms or are marked incorporated. Counting the same amendment twice is the failure mode this exists to prevent.
* **Clause sets are versioned.** Editing a reference clause never rewrites the history of reviews already run against the previous wording, so a review from last quarter still shows the standard it was judged against.
### The review's own history
Alongside the document lineage, each Guardian run keeps its own record: the system verdict per clause, the matched variant and tier, the confidence, the evidence with page citations, and the human triage decision layered on top. Re-run Guardian after an amendment and you get the new verdict beside the old one, so what changed in the controlled obligation surface is visible rather than inferred.
Where the contract arrived as a Word file, Guardian can return it with the counterparty's wording struck and your playbook's inserted as tracked changes, plus a comment per clause carrying the ask. It opens in the Review ribbon your counterparty already uses, which keeps the negotiation in the format legal teams redline in.
## How to integrate
Submit contract documents (PDF, DOCX) for analysis. Returns structured clause extraction and playbook deviation report.
Add amendments and addenda to the contract and rerun the review against the existing paper, surfacing what changed in the controlled obligation surface.
## Common workflows
Submit drafts to Guardian before legal review. It surfaces deviations from your playbook, missing clauses, and unusual liability terms so reviewers focus on the deltas rather than reading every contract end to end.
Bulk-process your existing contract portfolio. Guardian extracts obligations, surfaces gaps against your current playbook, and produces a prioritized list of contracts that need renegotiation.
Guardian-extracted obligations feed the Coverbase obligation surface, where they can be assigned, tracked, and linked to controls. When a vendor's risk profile changes in Supplier Radar, contractual obligations are already in scope.
Pair clause review with [Document Insights](/products/document-insights) to populate the contract record itself: value, term dates, notice periods, liability caps, and governing law extracted from every document with page citations.
Setting this up? The [Contract Guardian guide](/user-guides/contract-guardian) walks through building a clause set, writing risk-tier variants, and running your first review. Contract Guardian results integrate with the Coverbase obligation and finding surfaces, accessible through the [Export API](/export-api-concepts) and [MCP server](/mcp/overview).
# Corporate Registrations
Source: https://docs.coverbase.com/products/corporate-registrations
Validates the legal entity behind a vendor against public business registers, with a citation for every fact.
Most vendor records start life as a name and a website. **Corporate Registrations** answers the question that sits underneath every other piece of diligence. Is there a real, currently registered company behind this, and is it the one we think it is?
It runs automatically once a vendor has a website on file, and appears as the **Registrations** tab of a vendor's **Vendor Intelligence** section.
## Where the data comes from
All sources are public. Companies House needs a free key, which Coverbase configures.
| Source | What it contributes |
| - | - |
| **GLEIF** | The authoritative legal name and LEI, entity and registration status, jurisdiction, legal and headquarters addresses |
| **OpenCorporates** | Company number, jurisdiction, incorporation date, current status, and a link back to the originating registry |
| **The vendor's own legal pages** | The contracting entity, its former names, its subsidiaries and its registration numbers, quoted from its terms, privacy policy, imprint and footer |
| **Companies House** | Every UK company, private ones included: company number, status, incorporation date, registered office, and corporate owners |
| **SEC EDGAR** | US public-company validation: CIK, ticker, state of incorporation, industry classification |
| **Dun & Bradstreet** | DUNS number, surfaced when your organization already has D\&B credentials |
## Read the verdict first
The page leads with a match decision rather than with identifiers, because every identifier below it is only meaningful once you know they belong to *this* vendor.
A registered company was bound with high confidence. The identifiers can be relied on.
Something plausible was found but not confirmed. Two companies sharing a trading name in one jurisdiction is the usual cause. Check the identifiers before using them.
Nothing credible matched. Common for very small, very new, or non-corporate suppliers.
A match confidence accompanies the decision. Treat it as a measure of binding certainty, meaning how sure we are that these records describe your vendor. It says nothing about the company's health.
When no register holds the entity but the vendor names it on its own legal pages, the page shows that entity as **Identified from the vendor's own pages**, with the quotes. When several registered companies share the vendor's name, the page lists them as **Possible matches** for you to pick from.
To fix a wrong or missing entity, use **Correct with AI**: describe the right entity in your own words, see the match, and apply it. Your correction is kept for every later refresh. See the [Corporate registrations guide](/user-guides/corporate-registrations#correct-with-ai).
## What the page shows
LEI, company number, SEC CIK and DUNS. These are the registry keys that let you look the company up independently, anywhere else.
Whether the company is currently active, dissolved or inactive; its jurisdiction; incorporation date; whether it is publicly listed and under what ticker; and its industry classification.
A **dissolved** status on a vendor you are actively paying is one of the highest-signal findings in the product. It usually means a restructure nobody told you about, or that you are contracting with an entity that no longer exists.
The registered and headquarters addresses on file with the registers. These frequently differ from the trading address a vendor gives you, which is normal and not itself a finding.
The vendor's parents and subsidiaries, from GLEIF's relationship records, Companies House's corporate owners, and the entities the vendor names on its own pages. Each entity says whether a register holds it or only the vendor names it.
Every register checked and the identifier it returned, each linking back to the source record. Citations are listed per lookup rather than collapsed to one row per register, so it stays visible which fact rests on which record.
Caveats recorded while matching: why a candidate was rejected, or why two remain in contention.
## How it's used elsewhere
Corporate registration data feeds:
* **Financial Health Score.** Corporate standing is one of the scored pillars, and registry identifiers are how a vendor is resolved to filings in the first place.
* **Zero Touch Assessments.** Registration validation can be included as a scored component of the composite.
* **The vendor fact sheet.** The validated legal name and status appear in the company profile.
A missing registration record is not a red flag on its own. Sole traders, partnerships, and vendors in jurisdictions with no open registry data will legitimately return nothing. What matters is a record that comes back **dissolved**, or one that comes back describing a different company than the one you thought you were buying from.
# Coverbase Screening
Source: https://docs.coverbase.com/products/coverbase-screening
Continuous sanctions, PEP, criminal, legal and adverse media screening for your vendors and the people behind them, with a recorded history of every screen.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Coverbase Screening checks whether a vendor, or a person who runs or owns it, appears on a sanctions list, a watchlist, a politically exposed person (PEP) register, a criminal or legal record, or in adverse news. It checks at intake, again on a schedule for as long as you keep the vendor, and whenever you ask.
Every screen is recorded, including the ones that find nothing. "We screened this vendor on this date against these sources and found nothing" is the record an examiner asks for, so Coverbase keeps it whether or not there is anything to review.
## What you can screen
| Subject | Screened by default | How it is identified |
| - | - | - |
| The vendor's legal entity | Yes | Legal name, headquarters country, and the registration number when [Corporate Registrations](/products/corporate-registrations) has one |
| Directors and officers | Opt in | Names from registry filings and [People Intelligence](/products/people-intelligence) research |
| Beneficial owners | Opt in | Names from registry filings |
| Anyone else, once | On demand | An **Ad hoc screen** of any organization or person, with or without a linked vendor |
People are opt in because screening a person means storing watchlist results about a named individual. Turn them on when your program needs them.
## What you can screen against
Screening covers five sources. Each is a separate lookup that you switch on or off for your whole organization.
| Source | What it covers | Default |
| - | - | - |
| **Sanctions** | Government sanctions and designation lists, including OFAC, the EU, UK HM Treasury, the UN and national lists. FATF high risk and increased monitoring jurisdictions are included. | On |
| **PEP** | Politically exposed persons, and their relatives and close associates, across national, regional and local government, state owned enterprises, diplomatic and security roles, and political parties | On |
| **Criminal** | Law enforcement and terror watchlists, and records of criminal charges | On |
| **Legal** | Civil and criminal litigation, lawsuits and judgments | On |
| **Adverse media** | Negative news about the subject, scored against the risk categories you choose, from over 200,000 outlets in more than 140 languages | Off |
The full catalog of lists, PEP roles and adverse media categories is in [Screening coverage and sources](/user-guides/screening-coverage).
## How it works
An administrator chooses which sources run and who is screened under **Configuration → Monitoring → Screening**.
Monitoring is switched on per risk level, so you can monitor your critical and high risk vendors continuously and leave the long tail to intake and on demand screens.
A monitored vendor is re-screened on a cadence set per source. By default that is daily for sanctions and monthly for PEP and adverse media. Each screen lands in the vendor's run history.
A possible match goes to the **Screening** queue and opens a finding with an owner and a due date. An analyst confirms it, marks it not a match, or allowlists it for 180 days. Coverbase never decides a match for you.
## Where screening runs
* **At intake.** The intake portal's pre-qualification step screens a requested vendor before anyone commits to it. See [Screen a vendor at intake](/user-guides/sanctions-screening#screen-a-vendor-at-intake).
* **On a schedule.** Monitored vendors are re-screened for as long as they stay monitored.
* **On demand.** **Screen now** on a vendor's **Screening** tab, and **Ad hoc screen** on the queue for a name you want checked once.
## Included, and configured on request
Most of screening is switched on from the settings page. Some options are set up by Coverbase for your workspace, and some carry an additional charge. Contact your Coverbase account team or [support@coverbase.ai](mailto:support@coverbase.ai) to change them.
| Option | How you get it |
| - | - |
| Sanctions, PEP, criminal and legal screening of the vendor entity | Settings page |
| Directors, officers and beneficial owners | Settings page |
| Adverse media, and the 12 standard risk categories | Settings page |
| Monitoring by risk level | Settings page |
| A different monitoring cadence for a risk level | Ask Coverbase to set up a profile group, then pick it in the settings |
| Adverse media categories beyond the standard 12 | Ask Coverbase |
| Your own internal watchlists and do not onboard lists | Ask Coverbase. Enterprise plans only. |
| Tuning match scoring, repeated alert suppression, and filtering of articles that only mention a similar name | Ask Coverbase |
Each monitored subject is a standing subscription, and every on demand screen is metered. Your account team can tell you what your plan includes.
## Get started
Every source, list, PEP role and adverse media category Coverbase screens against.
Reading a match, deciding it, and setting up the screening policy.
The other outside-in research on every vendor.
Where a new vendor is screened before it is onboarded.
# Detector library
Source: https://docs.coverbase.com/products/detector-library
Every out-of-the-box Supplier Radar detector template, organized by segment, with the default severity and what each one flags.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Supplier Radar ships with a library of ready-to-use detector templates. Each template becomes a live detector on your organization when you enable it from the dashboard (**New detector → From detector library** on the Radar page, or **Add detector** under **Configuration → Radar → Detectors**). It watches your sources for events that match its focus, enriches matches with vendor context, and routes them into triage. This page documents each built-in template so you can decide what to turn on.
The library currently includes **95 detector templates**. The dialog filters them by **Recommended** and by segment: **Cybersecurity**, **Financial**, **Operational**, **Legal**, **Compliance**, **Reputational**, **Contractual**, **ESG**, **Corporate**, **Geopolitical & External** and **AI Risk**. The **Corporate** segment lists no templates today. Most templates are *standard* detectors that read a natural-language goal and severity guidance. One is a *watchlist* detector that screens vendors against connected sanctions lists, and five are *Black Kite* detectors that read your Black Kite portfolio directly, with no AI step.
Detector templates are a starting point. Enabling a standard or watchlist template also adds the library sources it names to your organization and scopes the new detector to them, so it works without further setup; the preview in the dialog lists those sources. Once applied, every detector's instructions, severity threshold, category filters, sources, and reviewers are fully editable in the dashboard, and detectors learn from dismissed alerts. See [Supplier Radar](/products/supplier-radar) for the product overview and [Radar API](/api-reference/radar) for programmatic access.
## Severity levels
Each template ships with a default severity threshold. Detectors surface matches at or above their threshold; you can raise or lower it per detector.
| Severity | Meaning |
| - | - |
| High | Confirmed, material impact: active exploitation, confirmed breach, insolvency, sanctions |
| Medium | Credible, significant events warranting review |
| Low | Early or lower-impact signals worth monitoring |
| Informational | Contextual updates (for example, ownership changes) tracked without urgency |
## Recommended
The five templates every new organization starts with, already enabled. They also appear in their own segment in the dialog.
| Detector | Segment | Default severity | What it flags |
| - | - | - | - |
| Vendor Data Breach & Exposure | Cybersecurity | High | Confirmed or credibly suspected access to, exfiltration of, or exposure of vendor-held data, including breach notification filings |
| Ransomware & Destructive Attack | Cybersecurity | High | Ransomware, extortion, leak-site listings, and destructive attacks on vendors or their upstream providers |
| Exploited Vulnerabilities & Supply Chain Compromise | Cybersecurity | High | Actively exploited vulnerabilities, emergency patches, and software supply-chain compromises in vendor products |
| Operational Resiliency & Service Disruption | Operational | Medium | Outages, degradations, facility and disaster impacts, strikes, and continuity events |
| Vendor Financial Distress | Financial | Medium | Bankruptcy, going-concern doubt, credit downgrades, distressed funding, delisting, and severe earnings deterioration |
## Cybersecurity
Attack-surface, threat-intelligence, breach, privacy, and infrastructure-security signals affecting your vendors.
| Detector | Default severity | What it flags |
| - | - | - |
| Actively Exploited Vulnerabilities | High | CVEs, zero-days, and vendor product flaws exploited in the wild |
| Ransomware Vendor Impact | High | Ransomware and extortion incidents affecting vendors or service delivery |
| Malware or Supply Chain Compromise | High | Malicious packages, compromised updates, and supplier supply-chain attacks |
| Nation-State or APT Targeting | High | Nation-state or APT campaigns targeting a vendor, its products, or its sector |
| Confirmed Data Breach | High | Confirmed unauthorized access to vendor or customer data |
| Health Data and HIPAA Breach | High | Breaches of protected health information and HIPAA enforcement |
| Critical Patch Advisories | Medium | Emergency patches and critical security advisories |
| Cloud Service Security Incidents | Medium | Security incidents at cloud, SaaS, hosting, and identity providers |
| Credential or Token Compromise | Medium | Leaked credentials, API keys, tokens, and accounts in breach corpora |
| Identity and Access Control Failures | Medium | MFA bypass, account takeover, and IAM failures |
| Phishing and Social Engineering Campaigns | Medium | Campaigns abusing vendor brands, platforms, or employee access |
| Internet-Exposed Services and Misconfigurations | Medium | Exposed databases, admin panels, and risky misconfigurations |
| Malicious Infrastructure and Domain Reputation | Medium | Vendor domains or IPs reported malicious, blocklisted, or serving malware |
| Possible Data Exposure | Medium | Suspected leaks, exposed databases, and leak investigations |
| Privacy Regulatory Investigations | Medium | Privacy inquiries and regulator scrutiny of data practices |
| GDPR, CCPA, and Data Protection Actions | Medium | Fines and actions under major data-protection regimes |
| Third-Party Data Sharing Concerns | Medium | Risky vendor sharing, sale, or onward-processing of data |
| DDoS and Service Disruption Attacks | Medium | Denial-of-service attacks disrupting vendor platforms or customer access |
| Insider Threat and Data Theft | Medium | Rogue-employee data theft, insider fraud, and privileged-access abuse |
| Dark Web and Underground Exposure | Medium | Vendor data, access, or credentials advertised on criminal forums. Separate from [dark web monitoring](/user-guides/dark-web-monitoring), which watches leak sites and breach catalogs directly |
| ICS, OT, and IoT Vulnerabilities | Medium | Industrial, operational-technology, and connected-device flaws |
| Breach Notification Filings | Medium | Official breach notifications filed with regulators or attorneys general |
| Children's Data and Sensitive-Population Privacy | Medium | COPPA, minors' data, and sensitive-population privacy issues |
| TLS and Certificate Weaknesses | Low | Weak, expired, or mis-issued TLS certificates and transport-security gaps |
| Domain, DNS, and Email Security Gaps | Low | Subdomain-takeover risk and missing SPF, DKIM, or DMARC |
| Open-Source Dependency Risk | Low | Critical vulnerabilities or abandonment in open-source components |
### Black Kite templates
These five read your Black Kite portfolio against fixed thresholds and carry a **Black Kite** badge in the library. They can be enabled only once a Black Kite portfolio source is connected; see the [Black Kite monitoring guide](/user-guides/black-kite-monitoring).
| Detector | Default severity | What it flags |
| - | - | - |
| Exploited Vulnerabilities | High | A CISA KEV-listed vulnerability Black Kite found on a vendor's internet-facing infrastructure, with no susceptibility threshold |
| Critical Exploitable CVEs | High | Exploited vulnerabilities scoring CVSS 9.0 or higher with at least a 50% predicted chance of exploitation |
| Vulnerability Campaign Exposure | High | Black Kite focus tags naming a vendor as exposed to a campaign, such as a mass-exploited flaw or a ransomware wave |
| Ransomware-Susceptible Vendor Exposure | High | Exploited vulnerabilities and focus tags, only for vendors scoring above 0.5 on ransomware susceptibility |
| Highest Susceptibility Watch | High | The same signals, only for vendors scoring above 0.8 on ransomware susceptibility |
## Financial
Financial-stability, credit, financial-crime, and concentration signals.
| Detector | Default severity | What it flags |
| - | - | - |
| Bankruptcy or Insolvency Risk | High | Bankruptcy filings, insolvency warnings, and going-concern risk |
| Credit Rating Downgrades | Medium | Rating downgrades, covenant breaches, and debt-risk signals |
| Accounting or Internal Control Issues | Medium | Restatements, audit concerns, and control failures |
| Financial Crime Compliance | Medium | AML, KYC, sanctions, fraud, and market-abuse actions |
| Funding and Runway Risk | Medium | Down rounds, failed raises, and cash-runway warnings |
| Delisting and Exchange Warnings | Medium | Stock delisting notices, exchange warnings, and going-private distress |
| Adverse Media & Financial Crime | Medium | Fraud, money laundering, sanctions violations, corruption, and executive misconduct allegations |
| Financial Regulatory Enforcement & Supervisory Actions | Medium | Enforcement and supervisory actions by financial regulators such as the SEC, CFPB, OCC, FDIC, FINRA, and FinCEN |
| Fourth-Party & Concentration Risk | Medium | Incidents at shared subcontractors, subprocessors, and upstream providers, especially ones many vendors depend on |
| Earnings or Guidance Downgrade | Low | Material revenue, margin, or forecast deterioration |
| Insurance Coverage Risk | Low | Loss of cyber, liability, or required insurance coverage |
| Macroeconomic & Market Stress | Low | Credit-market, banking, currency, and rate shocks that could reach vendor viability or delivery |
| Concentration and Single-Source Risk | Informational | Signals that many customers depend on a single vendor or provider |
## Operational
Service, continuity, and corporate events that affect a vendor's ability to deliver.
| Detector | Default severity | What it flags |
| - | - | - |
| Service Outages and Degradation | Medium | Outages, degraded service, and major incident reports |
| Business Continuity Disruption | Medium | Events threatening a vendor's ability to operate or deliver |
| Product Recalls and Safety Issues | Medium | Recalls, safety alerts, quality failures, and hazardous products |
| Subprocessor and Fourth-Party Risk | Medium | Incidents at a vendor's critical subprocessors and fourth parties |
| Certification and Attestation Lapse | Medium | Expired, withdrawn, or failed SOC 2, ISO, and other certifications |
| Customer Support and Service Failures | Low | Widespread complaints about support, delivery, or service quality |
| Workforce Instability and Layoffs | Low | Mass layoffs and key-personnel departures signaling instability |
| M\&A and Change of Control | Informational | Acquisitions, divestitures, leadership shifts, and ownership changes |
## Legal
Enforcement, litigation, and conduct matters with material vendor impact.
| Detector | Default severity | What it flags |
| - | - | - |
| Government Contracting Suspension | High | Debarment, suspension, procurement bans, or contract termination |
| Regulatory Enforcement Actions | Medium | Formal enforcement, consent orders, penalties, and corrective actions |
| Material Lawsuits and Class Actions | Medium | Litigation affecting vendor stability, obligations, or reputation |
| Anti-Bribery and Corruption | Medium | Bribery, corruption, FCPA, sanctions evasion, and misconduct |
| Labor and Human Rights Actions | Medium | Forced labor, labor violations, and worker-rights disputes |
| Intellectual Property Infringement | Medium | Patent, copyright, or trade-secret suits threatening products |
| Data Localization and Sovereignty Actions | Medium | Data-residency, cross-border transfer, and sovereignty enforcement |
| Antitrust and Competition Actions | Low | Antitrust probes, competition rulings, and market-power enforcement |
## Compliance
Deterministic screening against connected sanctions and watchlist sources. It needs a watchlist source; enabling it adds the OFAC SDN list from the source library if you have none.
| Detector | Default severity | What it flags |
| - | - | - |
| Watchlist Screening | High | Screens monitored vendors against connected sanctions and watchlist sources |
## Reputational
Media, conduct, and trust signals that may warrant a vendor review.
| Detector | Default severity | What it flags |
| - | - | - |
| Executive Misconduct | Medium | Misconduct, resignations, investigations, and governance concerns |
| Whistleblower Allegations | Medium | Credible whistleblower disclosures of misconduct or safety failures |
| Negative Media Spikes | Low | Sudden negative coverage that may require review |
| Major Customer Losses | Low | Loss of key customers, partnerships, or market trust |
| Misinformation or Harmful Content | Low | Content-moderation, platform-abuse, and harmful-use issues |
| Security Reputation Drop | Low | Public downgrades or negative analyst reports on security posture |
| Social Backlash and Boycott | Low | Viral backlash, boycotts, and coordinated reputation campaigns |
| Greenwashing and ESG Misrepresentation | Low | Misleading sustainability, diversity, or ESG claims |
## Contractual
Contract performance signals.
| Detector | Default severity | What it flags |
| - | - | - |
| Contractual SLA Penalties | Medium | Penalties, contract breaches, and SLA failures |
## ESG
Environmental enforcement and sustainability signals.
| Detector | Default severity | What it flags |
| - | - | - |
| Environmental Enforcement | Medium | Environmental fines, pollution incidents, and permit violations |
## Geopolitical & External
Sanctions, export controls, geopolitical events and natural hazards touching vendors or their regions.
| Detector | Default severity | What it flags |
| - | - | - |
| Geopolitical & Sanctions Exposure | High | Sanctions designations, export controls, conflict, and instability touching vendors or their operating regions |
| Geopolitical or Sanctions Disruption | Medium | Geopolitical exposure, sanctions, export controls, or instability |
| Natural Hazard Near a Supplier Site | Medium | Earthquakes, storms, floods, wildfires and severe weather reaching the location of a vendor's site. See the [natural hazard monitoring guide](/user-guides/natural-hazard-monitoring) |
## AI Risk
AI- and model-specific incidents, security, governance, and regulatory signals, for vendors that build or depend on AI systems.
| Detector | Default severity | What it flags |
| - | - | - |
| AI Security: Jailbreaks and Prompt Injection | High | Jailbreaks, prompt injection, and adversarial exploitation of vendor AI |
| AI Data Leakage and Training-Data Extraction | High | Sensitive-data leakage via AI systems, memorization, or training-data extraction |
| AI Model Supply-Chain and Provenance | High | Poisoned models, malicious artifacts, and compromised model-hub supply chains |
| AI Security & Data Leakage Incidents | High | Exploited jailbreaks and prompt injection, data leakage, poisoned models, and compromised AI supply chains |
| Biometric and AI Privacy Risk | Medium | Privacy issues tied to biometrics, AI systems, and automated decisions |
| AI Model Safety Incidents | Medium | Unsafe, harmful, or out-of-scope AI outputs and model-behavior incidents |
| AI Training-Data and IP Disputes | Medium | Copyright, licensing, and IP litigation over training data and outputs |
| AI Regulatory Enforcement | Medium | EU AI Act and other AI-specific regulatory action and enforcement |
| AI Bias and Discrimination | Medium | Algorithmic bias, discriminatory outcomes, and automated-decision harm |
| AI Model Outage & Deprecation | Medium | AI/LLM API outages, model deprecations, and capability changes |
| AI Deepfake and Brand Impersonation | Medium | Deepfakes and synthetic media impersonating a vendor or its executives |
| AI Legal, Regulatory & IP Actions | Medium | AI-law enforcement, training-data IP litigation, bias claims, and biometric and AI privacy actions |
| AI Safety, Deepfake & Misuse Incidents | Medium | Harmful AI outputs in vendor products and deepfake abuse of a vendor's brand, executives, or platform |
| AI Governance and Transparency Gaps | Low | Responsible-AI program failures, missing disclosures, and governance lapses |
| Shadow AI and Unsanctioned Use | Low | Unsanctioned AI-tool use that may expose customer or regulated data |
| Vendor AI Adoption & Data-Use Changes | Low | New AI features, changed AI data-use or training practices, new AI subprocessors, and undisclosed AI use |
## Related
The companion library of built-in source templates that these detectors read from.
The product overview: signal ingestion, enrichment, triage, and workflow orchestration.
Create radar events, and list, retrieve, and dismiss radar alerts programmatically.
The companion library of built-in control-set templates, including AI governance frameworks.
Subscribe to `RadarDetectorResult.*` events and react in real time.
# Document Insights
Source: https://docs.coverbase.com/products/document-insights
Org-defined fields extracted from every document, with a verbatim source quote, page citation, and confidence on each value.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Document Insights turns any document your organization collects into structured, queryable data. You define the fields once (an effective date, a liability cap, a breach-notification window, an audit period), and Coverbase populates them automatically whenever a matching document is processed. Every value carries a verbatim source quote, a page citation, and a confidence level, so a reviewer can verify it without opening the file.
Insights are the field-level layer of contract intelligence. [Contract Guardian](/products/contract-guardian) is the language-level layer, comparing vendor clause language against your playbook. They run over the same documents and feed the same records.
## What it does
You decide what gets extracted. Each insight has a name, a description that instructs the model, a value type (text, number, date, yes/no), and a mode. No fixed schema to work around.
Every value is checked against the document. The supporting quote must appear in the source as a contiguous span, and the cited page is corrected to where the quote lives. An answer whose quote cannot be located is kept but marked unverified, and waits for a reviewer to accept it.
Insights apply to the document types you choose, individually or through groups that share scope. A liability-cap field runs on MSAs, not on SOC 2 reports.
**Extract** returns one concise, typed answer: a name, a date, a number, or Yes/No. **Synthesize** writes a short summary for a Text insight. Both cite the language that supports the answer.
## Extract vs Synthesize
The mode determines the shape of the answer: a single typed value, or a written summary.
| Mode | Behavior | Use it for |
| - | - | - |
| **Extract** | One concise answer in the insight's type. The model prefers the document's wording and interprets only as far as the type needs, so a Yes/No insight reads the clause and answers Yes or No. It must cite a verbatim quote, which Coverbase checks. Returns empty when the document can't answer. | Dates, party names, jurisdictions, figures, named frameworks, yes/no judgments: anything you want as one value to sort and filter on |
| **Synthesize** | The model writes a short summary that combines or explains what the document says, and must cite a verbatim quote supporting it. Available for Text insights only. Returns empty when the document can't answer. | Rollups across sections, plain-language verdicts, the gist of terms every counterparty words differently |
**Yes/No**, **Number** and **Date** insights always use Extract, because Synthesize only takes Text. A Yes/No, Number or Date insight created earlier with Synthesize now runs as Extract and needs no change.
The [Document Insights guide](/user-guides/document-insights) covers mode selection in depth, along with a starter library of insight definitions to copy.
## What each value carries
| Field | Description |
| - | - |
| Value | Stored in its declared type. Dates normalize to ISO `YYYY-MM-DD`; numbers strip currency symbols and separators |
| Source quote | The exact span from the document supporting the value, verified to exist in the source |
| Page number | 1-indexed physical page containing the quote |
| Confidence | `high` when explicitly stated, `medium` when inferred, `low` when uncertain |
| Reasoning | Notes on ambiguities or assumptions made during extraction |
| Source type | `ai_extracted` or `manual`, so hand-corrected values are always distinguishable |
## How it runs
When a document finishes processing, every enabled insight matching its type is extracted in the same pass. Insights grouped by mode run as separate calls.
Re-extract a whole document or a single insight after you add or reword a definition.
A new definition starts empty on documents already processed. A backfill re-extracts them in bulk, scoped by insight, document type, or vendor, with a cost estimate before it runs.
PDFs are read natively, including their layout. Long documents are chunked with page overlap and results merged, preserving original page numbering. Excel workbooks are grounded per worksheet.
Insights roll up onto the contract record, feed the contract AI summary, and export to CSV with every value, citation, and confidence intact.
## Auditing coverage
Defining insights is the easy half. Knowing whether they *worked* is the half that decides if anyone trusts the data.
**Configuration → Document Insights** is the module for that. It shows the same set of extractions through three lenses:
| Lens | Answers |
| - | - |
| **Insights** | What have we defined, and is each definition healthy? |
| **Document types** | Is this document type well covered? A matrix of document type against insight, with a fill rate in every cell |
| **Extractions** | Is this specific value right? Every extraction in the org, filterable by confidence, groundedness, and source |
### The number that matters
A blank cell in the coverage matrix means one of two opposite things, and the module keeps them apart:
Extraction ran and found nothing. Either the definition is ambiguous, or the term genuinely isn't in that document. This is a **prompt problem**. Open the Extractions tab and read what it returned.
The insight was created after the document was last processed, so it has never run against it. This is a **backlog problem**; one backfill fixes it. The matrix marks these as *stale*, and the badge is the button.
## Promoting insights into custom fields
An extraction lives on a document. A custom field lives on the record people work from: the vendor, the contract, the assessment. Promotion connects them.
Link an insight to a custom field and Coverbase fills that field from the extraction whenever a matching document is processed, then backfills the field across every document you already hold. The field keeps a pointer to the document, page, and verbatim quote it came from, so a value on a contract record can show you *why* it holds that value.
| Insight type | Fills a custom field of type |
| - | - |
| Text | Text |
| Number | Number |
| Date | Date |
| Yes/No | True/False |
Select and multi-select fields are not promotable yet. Mapping free text onto a fixed option list needs the options fed into the prompt, not matched after the fact.
Two gates decide what gets promoted, and one rule is absolute:
* **Require a grounded quote** (on by default) skips any answer whose supporting quote could not be located in the source.
* **Minimum confidence** skips answers below the bar you set.
* **A value a person typed is never overwritten.** Not by a backfill, not by a later upload, not by any conflict policy. Automated writes only ever replace other automated writes.
## Common workflows
Define the fifteen fields your team asks of every agreement (value, effective date, term, renewal, notice period, liability cap, governing law, data return, audit rights) and get them populated on every contract as it lands, instead of maintaining a spreadsheet by hand.
Extract audit periods, report scopes, certification expiry dates, and auditor names from SOC 2s and ISO certificates so evidence freshness can be tracked without a human reading each report.
Once a field exists on every contract, portfolio-wide questions become answerable: which agreements auto-renew inside 60 days, which permit customer data in model training, which cap vendor liability below one year's fees.
An answer whose quote could not be verified is flagged for review, and a reviewer can accept it with the evidence still marked unverified. A value set through the API is marked as manual with the user recorded, and automated writes never overwrite it.
Insight values surface on the document, on the contract record, in the contract AI summary, on any custom field you promote them to, and through the [MCP server](/mcp/overview) for natural-language querying.
# Document library
Source: https://docs.coverbase.com/products/document-library
The library of vendor documentation Coverbase collects and curates itself: where the documents come from, how they are reviewed, and why nothing you upload ever ends up in it.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Open the **Documents** tab on almost any vendor and you'll find a section called **Coverbase library documents** that is already populated. A SOC 2 report, an ISO certificate, a pen test summary. Nobody on your team put them there, and people reasonably want to know two things: where these came from, and whether their own documents are sitting in someone else's account the same way.
## What the library is
The document library is vendor documentation that **Coverbase collects and curates itself**, so a vendor's evidence is often waiting for you before you've asked anyone for it. It's keyed to the company rather than to your organization. Coverbase resolves each vendor record to a canonical company, and every customer assessing that same company sees the same library.
Our agent requests documentation from the vendor and retrieves what they publish, on our own initiative.
Nothing reaches the library until a Coverbase reviewer has approved it.
Documents you or your vendors upload to Coverbase are never added to the library.
## Where the documents come from
There are two routes, both run by Coverbase and neither triggered by a customer asking for anything.
* **We ask the vendor.** Our agent requests documentation from the company directly, on Coverbase's own behalf. This is how the library gets hold of material that isn't published anywhere.
* **We retrieve what the vendor publishes.** Trust centers (Drata, Vanta, SafeBase, custom portals), certification registries, and official disclosures. Anything ungated is downloaded, and for gated material the agent completes the access request.
What we don't do is scrape the open web for anything that looks like a vendor document. Material harvested that way is usually stale, often the wrong version, and sometimes not the vendor's document at all. A library full of that is worse than an empty one, because it still looks authoritative sitting in an audit file. Three current documents beat thirty scraped ones.
This is separate from how an assessment researches the public web while evaluating a control. That path has its own accountability filter and is documented in [Evidence quality and source credibility](/user-guides/evidence-quality).
## What never goes into the library
**Your documents stay yours.** Nothing your organization uploads to Coverbase is ever added to the document library, and nothing a vendor sends you through an assessment portal is either. There is no path, manual or automated, that promotes a customer-owned document into the shared library.
This isn't only a policy. It's how the system is built:
* Only Coverbase staff can add a document to the library. The write path is closed to customer organizations completely, so a document can't land there from your side even by accident.
* Everything in the library was obtained by Coverbase on our own initiative, not in response to any customer's request or upload.
* Your own vendor documents live in a separate, org-scoped store, under the tenant isolation described in [Data protection](/security/data-protection). They appear on your vendor's Documents tab in their own section, above the library.
The two sections on that tab come from completely different places. The upper one is yours and private to you. The lower one is ours and shared.
## How documents are curated
The agent requests or retrieves the document and files it against the company.
Each document is given a type (SOC 2 Type II, ISO 27001 certificate, pen test report, and so on), a publication date, and an expiry date.
A Coverbase reviewer checks the document before it is approved. Until then it isn't visible to anyone outside Coverbase.
Expiry follows the document type, not a single global rule: attestations and pen tests age out faster than company policies. Expired documents are hidden by default, with a **Show expired** toggle when you want to see them anyway.
## Where you'll see it
The card carries a short explanation of its own. Click the question mark next to the heading for the same answer this page gives, without leaving the vendor.
![Coverbase library documents card showing the help popover that explains where library documents come from]()
The **Documents** tab shows **Coverbase library documents** below your organization's own documents. **Import** on a row copies that document into your organization's own documents; a file you already hold is skipped.
**Import from Coverbase Library** is one of the five evidence-collection routes, showing the count available before you click. See [How to run an assessment](/user-guides/running-an-assessment#part-3-collect-the-evidence).
![Assessment Documents tab, with Import from Coverbase Library showing 27 documents available]()
When you import a library document into an assessment, or with **Import** on the vendor's **Documents** tab, Coverbase copies the file into your organization and attaches the copy as a vendor document. Duplicates are skipped, so the same file is not attached twice.
## Frequently asked questions
No. Customer-uploaded documents are org-scoped and are never promoted into the library. Only Coverbase staff can add library documents, and every one of them was obtained by Coverbase independently.
Because the library is built ahead of demand. Coverbase collects documentation for companies across its coverage, so a well-known vendor often has substantial evidence waiting before anyone assesses them. It doesn't mean someone in your organization requested it.
For most evidence, yes. It's the vendor's own document, retrieved from the vendor or their trust center and reviewed before publishing. Check the publication and expiry dates the way you would for any document, and go to the vendor directly when you need something scoped to your specific engagement.
Tell us at [support@coverbase.ai](mailto:support@coverbase.ai). Corrections apply at the library level, so a fix reaches everyone assessing that company rather than only your organization.
## Related
The full walkthrough, including all five evidence-collection routes on the Documents tab.
How web evidence is graded for publisher accountability before it can be cited in an assessment.
The browser-based inspection that reads vendor trust centers and converts attestations into verified evidence.
Encryption, tenant isolation, retention, and deletion for the data your organization owns.
# Due diligence
Source: https://docs.coverbase.com/products/due-diligence
How each Risk Group gathers evidence and works with the vendor: assessment methods and review sessions, question delegation in the portal, answers carried forward from last time, reviewer edits the vendor approves, service-level questionnaires, findings raised on a question, and the acceptance chain for risk.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Due diligence is the work your Risk Groups do on an assessment: collecting the vendor's answers and evidence, meeting the vendor where a questionnaire is not enough, and deciding what to do about each finding. These capabilities sit on top of [Assessment Copilot](/products/assessment-copilot) and the [supplier portal](/user-guides/centralized-supplier-portal). They change how evidence is gathered and who signs off on risk, not how controls are evaluated.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
## What it does
Each assessment records how evidence is gathered: **Questionnaire**, **Remote review** or **Onsite**. Remote and onsite reviews schedule review sessions with a time, a place or link, internal participants and vendor attendees, who are notified when a session is scheduled, changed or cancelled.
A supplier can hand a section, or individual questions, to a colleague. A question assignment wins over its section's, which wins over the whole form's, and the portal shows who answered what.
When the same questionnaire goes to a vendor again, their previous answers are copied in. The vendor confirms each one or changes it, and cannot submit until every carried-forward answer is confirmed or updated. Reviewers see which answers changed.
When a reviewer edits a vendor's answer, the vendor sees the before and after in the portal and either approves the edit or suggests different wording.
Questions can be marked service-level. When a vendor's company-wide due diligence is current, a new service can be sent only those questions instead of the whole questionnaire.
A finding records what it was raised on: a question, a risk domain, a questionnaire, an assessment, a service or the vendor. A reviewer can raise one directly on a question from the vendor's answer.
## The acceptance chain
Accepting a finding's risk can be routed through a chain of people instead of one approver. Rules under **Findings Settings** match a finding by its severity or risk level, first match wins, and name:
1. The **finding owner**, who proposes to accept the risk, have the vendor remediate, or escalate.
2. An optional **recommending group**, typically the Risk Group for the domain, which recommends.
3. A **deciding group**, typically the TPRM Office, which decides and may decide at any point, overruling what came before. The overrule is recorded as one.
4. An optional **extended approver**, who must also approve an acceptance that runs longer than the rule's number of days.
An acceptance always has an end date, at most 366 days out. Once a finding is routed, every way of moving it to risk accepted, from the finding page, a bulk action, an import, a workflow or the API, is refused until its chain has approved the acceptance, and the exception it creates cannot outlast the end date the chain approved. A finding that no rule matches follows the single-approver path. See [The issue acceptance chain](/user-guides/issue-acceptance-chain).
![Finding Legacy backups stored unencrypted with the matching routing rule, its effect on residual risk, and a decision path in which the owner proposed accepting the risk, Privacy escalated, and the TPRM Office overruled with Remediate]()
## When the vendor's due diligence is current
The abbreviated, service-level send is offered only when the vendor has a completed assessment and its next assessment date has not passed. Otherwise the option is disabled and explains why.
## What it does not do
* Carried-forward answers are matched by question across questionnaire versions. A question added since the last submission starts empty, and nothing the respondent has already answered on the new request is overwritten.
* An onsite review does not upload evidence for you. Reviewers upload what they collected and record control effectiveness by hand from the assessment.
* The acceptance chain does not change who may raise or close a finding. It governs accepting risk only.
## Checking answers against evidence
[Claim check](/products/claim-check) tests each answer on a submission against the vendor's SOC reports, certifications, trust center documents, outside-in scan, licensed ratings and contract terms, marks it **Supported**, **Contradicted**, **Needs evidence** or **Not covered** with the cited passages, and lets the reviewer raise a finding or ask the vendor to clarify from the result.
## Where to go next
Methods, sessions, delegation, carry-forward, edit approval and service-level sends, step by step.
Set up routing rules and record proposals, recommendations and decisions.
How completed domain reviews add up to a Risk Summary for the Transaction Owner.
Statuses, commitments and remediation once a finding exists.
# Engagement record and Risk Summary
Source: https://docs.coverbase.com/products/engagement-record
The engagement as the Transaction Owner sees it: where the request is, each Risk Group's review, the due diligence that counts toward it, and the Risk Summary they decide on.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
An engagement is one piece of business with a vendor: the service a Transaction Owner is buying. The engagement record puts everything that happens to that piece of business on one page, so the person who asked for it can see where it is without asking the TPRM Office, and the TPRM Office can see which Risk Groups are still working.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
![Engagement page for Consumer analytics platform with the Where This Request Is tracker at the Decision stage, a Decide whether to proceed to-do, and Risk Groups reading 8 of 8 complete, 2 reused]()
## What it does
**Where This Request Is** shows the stage (Request, Triage, Inherent risk, Due diligence, Decision, Contract, Active, Exit) and an expected decision date. Everyone involved in the engagement sees the same tracker.
Each risk domain that needs a review shows its status: Complete, Reused, In review, Waiting on vendor or Not started, with the reviewer.
Assessments are linked to the engagement. A linked assessment performed for something else can be marked as reused, and a Front Door reuse decision links the prior assessment automatically.
Per domain: inherent risk, control effectiveness and residual risk, read live from the linked assessments. The TPRM Office adds a recommendation and conditions, the Transaction Owner records the decision, and the summary downloads as a PDF.
The Transaction Owner and the TPRM Office are told when due diligence goes out to the vendor and when it completes. The Transaction Owner receives the Risk Summary automatically when the last Risk Group signs off.
Set a vendor's parent company to see the family's rating, contract value and engagements rolled up to the ultimate parent.
## When due diligence is complete
A risk domain needs a review on a linked assessment by the same rule the assessment's own review progress uses. A domain is **complete** when every performed assessment that needs it has finished its review of it, and **reused** when a reused assessment has. Due diligence is complete when every domain is one or the other. Archived and canceled assessments drop out.
A Front Door reuse decision satisfies exactly the domains it marked for reuse, and nothing it marked for an abbreviated review or new due diligence.
## The Exit stage
Exit is the eighth stage, after Active. An engagement reaches it when someone files an offboarding request for it that is not canceled or archived.
* While the request is requested or in progress, Exit is the current stage and reads **Exit under way**. Every earlier stage shows as done, and the header badge reads **Exiting**.
* Once the offboarding completes, Exit shows as done with **Exited** and the date, and the header badge reads **Exited**.
* A live engagement with no exit planned keeps Active in focus, reading **Live since** and the date the contract went live, with Exit upcoming.
Program Insights counts an exiting engagement as active until its exit completes. An exited engagement leaves the program's figures. The engagement list's **Stage** filter includes **Exiting** and **Exited**.
![Where This Request Is tracker with Request through Active done and the Exit stage current, reading Exit under way]()
## The expected decision date
The expected decision date is when the last open domain review's SLA runs out. A review already running uses its remaining time; one not started uses its full target, counted from when the vendor's open request is due, or from today. Business days follow the SLA clock. If any open review has no SLA target, no date is shown, and none is shown once a decision is recorded.
## The decision
Only the Transaction Owner, or someone who can update the vendor, records the decision, and only once due diligence is complete. **Proceed to contracting** opens the contract handoff for Supply Chain, unless one is already pending or done. **Don't proceed** records the decision and stops there.
The Transaction Owner is the engagement's relationship owners (people and groups) plus whoever raised the intake request a linked assessment came from. An engagement with no owners of its own falls back to the vendor's.
![Risk Summary for Orbitline Data Services recommending Proceed with conditions, a Risk by Domain table with inherent, control effectiveness and residual levels, and a Decision card with Proceed to contracting and Don't proceed buttons]()
## Delivery tracking
The **Delivery** card on the Risk Summary shows, for each recipient, whether the summary is **Sent**, **In their notifications**, **Seen** or **Read in app** in Coverbase, and when it was emailed.
Email open tracking is off by default. An admin can turn on **Risk Summary Open Tracking** under **Configuration → Communications → Lifecycle Routing and Reminders**. With it on, the Risk Summary email, and no other email, carries a tracking pixel, and the card shows **Email opened** with the date of the first open, or **Email not opened yet**.
* Only the first open is kept. The recipient's mail client, operating system, IP address and location are discarded and never stored.
* An open is an image load. A mail client that blocks images never reports one, and a security scanner that fetches images can report one before anyone read the email. Treat an open as a signal; **Read in app** is the stronger fact.
* A summary sent to someone on a digest arrives inside a grouped email, which is never tracked.
* Turning tracking off stops it at once. Opens already recorded keep showing.
## Where to go next
Link diligence, read the tracker, write the recommendation and record the decision.
Where reuse decisions are made.
What the engagement owes once it is active.
The contract handoff, continuity plans and the exit.
# Financial Health Score
Source: https://docs.coverbase.com/products/financial-health-score
A 0-100 view of whether a vendor is financially sound enough to depend on, computed from filed statements where they exist and from signals where they do not, always labelled with which.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The Coverbase Financial Health Score answers one question about a vendor without asking the vendor anything: **is this company financially sound enough to depend on?** It runs 0-100, where higher is healthier, and it is computed from regulatory filings where a company files them and from funding, headcount, and corporate-standing signals where it does not.
What makes it usable in practice is how it's acquired: no supplier outreach, no questionnaire, no waiting on a vendor to opt in. Coverage is portfolio-wide from day one, and every vendor is rescored on each Vendor Intelligence run.
This is an optional feature. Ask your Coverbase representative to turn it on for your organization.
## What it does
Every score is published with the confidence tier behind it, so an inferred number is never presented with the authority of an audited one. The tier is derived from what resolved, never declared.
A ratio only means something against a comparable set. Coverbase ranks each vendor inside its own industry cohort, drawn from thousands of filers that reported the same concept in the same period.
Open the rationale on any pillar and you get the inputs behind it: each one's measured value, what it scored, how heavily it counted, and whether it was ranked against peers.
A bankruptcy filing or a dissolved registration doesn't get averaged into a weighted mean. It pins the score, and the card says which rule fired.
## Confidence tiers
**This is the most important thing on the card.** A Tier C 72 and a Tier A 72 are different claims about different evidence. The tier travels with the score everywhere the score goes: into the API, into MCP answers, into exports.
| Tier | Backing data | What you get |
| - | - | - |
| **A: Filed financials** | Financial statements the company filed with a regulator (SEC EDGAR XBRL), or statements you submitted yourself | The full ratio battery, ranked against peers. Statement-grade. |
| **B: Estimated financials** | Estimated revenue and EBITDA plus capital structure, where your organization has an estimates provider enabled | Partial ratios computed on estimates, full capital position and momentum |
| **C: Signals only** | Funding, headcount, corporate standing, and adverse events | Capital position, momentum, standing, and events. No financial statements were available. |
If a vendor's filings stop resolving, it drops to a lower tier and the card says so. It does not keep presenting a statement-grade number built on estimates.
Scores are held to a common scale across tiers by the stability class below, so ranking a mixed portfolio on the raw number is reasonable. The tier still tells you how much evidence stands behind any individual result, and it belongs in any conversation about a surprising one.
## Stability classes
A single number cannot order companies that survive by different mechanisms. An entrenched, cash-generative incumbent and a venture-funded startup are not two points on one axis, and treating them as one produces a ranking that is hard to defend in front of a customer.
Every vendor is therefore assigned a **stability class**, derived from observable scale, operating history, cash generation and dependence on outside capital. Never from a name, a ticker, or an opinion.
| Class | Roughly |
| - | - |
| **Entrenched incumbent** | Files audited statements, very large, long-established, generates cash |
| **Established operator** | Real revenue or headcount, years of history, covers its own costs |
| **Funded scale-up** | Past the fragility of a small team, still funded rather than self-sustaining |
| **Early-stage, capital-dependent** | Small or young, dependent on the next raise |
| **Distress signals present** | Insolvency, closure, or cash running out |
Each class occupies a score range, and the ranges are ordered so an early-stage company's ceiling never reaches an established company's floor. A vendor that recently raised cannot out-rank a profitable incumbent on inference alone.
Two limits on that. **Evidence outranks inference:** the ranges constrain what may be inferred, and a bankruptcy filing or going-concern opinion drives a score straight through any floor. And **every adjustment is published.** Where a floor or ceiling moved a score, the card shows the rule, the reason, and the before-and-after figures, so a corrected number does not read as a computed one.
## Runway and burn for private companies
For the majority of a portfolio that files nothing, the score models how long the company's cash lasts.
Burn is derived from headcount rather than guessed. Fully-loaded cost per employee is the operating figure that behaves most predictably across software companies, adjusted for stage and grossed up from personnel to total operating cost. Revenue is netted off at gross margin, using a conservative stage estimate where no figure is available. Capital is the last round plus a reserve, less what has been consumed since.
The output is a **range**, along with two readings that often matter more than the midpoint: whether the company is **self-sustaining** (revenue covers burn, so no cliff applies), and its **capital efficiency** (revenue per dollar raised). Every assumption used is recorded on the scorecard.
Most private rounds are reported with a size but no closing date. Crediting the vendor with a round closed yesterday flatters it, and charging a fixed number of months of burn penalises the companies with a large payroll. So an undated round is treated as half spent: observing a company at an unknown point in its funding cycle is observing it, on average, halfway through.
These are bounded estimates, labelled as such. They separate a vendor with two years of cover from one with two quarters, which is the distinction that affects a buyer. They are not a guess at a bank balance.
## Funding and headcount without a data subscription
The model above needs a headcount and, ideally, a last round. Crunchbase and PitchBook supply both, for the customers who license them and for the vendors those providers happen to cover.
Coverbase's own enrichment also researches each vendor's employee count, last round size, round type and founding year from public sources, and the score reads those directly. For a portfolio with no financial-data subscription behind it, that is the difference between a cash model that runs and one that never had a headcount to price.
Two rules apply. Researched figures are cited as **Web research** rather than attributed to a provider Coverbase never called, and they never raise a vendor's confidence tier, because a search result is not a filing however precise it looks. Where a licensed provider does answer, its figure wins and the researched one fills gaps only.
## What the score is built from
Five pillars. Which ones carry the score depends on the tier, because a tier with no filed statements has nothing to put in the financial core:
| Pillar | Tier A | Tier B | Tier C | What it covers |
| - | -: | -: | -: | - |
| Financial core | 50% | 30% | n/a | Margin, liquidity, leverage, coverage, and cash generation from filed statements |
| Capital position | 15% | 30% | 40% | Runway, debt maturity proximity, time since last raise, down-round history |
| Momentum | 15% | 20% | 30% | Direction of travel: revenue growth, headcount trend, funding cadence |
| Adverse events | 15% | 15% | 20% | Distress events weighted by severity, decayed by age |
| Corporate standing | 5% | 5% | 10% | Registration status, jurisdiction, filing compliance |
The weights renormalize over the pillars that exist for a vendor, which is why a Tier C score is not a Tier A score with holes in it.
## How a score is computed
A single outlier filer shouldn't set the top or bottom of the scale for everyone else.
This is the step that does the real work, and it matters more than any weight. It's what makes 4x debt/EBITDA at a utility and at a software company comparable. Ratios where lower is better (leverage, days sales outstanding, burn) are inverted so that higher always means healthier.
Where the trend matters as much as the level, the input score is weighted toward the current level but carries a meaningful share of the direction it's moving.
The events pillar doesn't percentile-rank. It sums decayed severity, so a two-year-old event does not weigh the same as last month's. Positive events carry negative severity and pull the burden back toward zero.
Each pillar is a weighted mean over the features present; the composite is a tier-weighted mean over the pillars present.
Damps routine churn so the score doesn't jitter on noise.
A model grades the vendor's resilience from the same evidence the card lists, and nothing else. Its grade carries 20% of the score at Tier A, 35% at Tier B and 50% at Tier C, less when the model is unsure, and it can never move the score by more than 20 points. If the grade fails, the arithmetic stands on its own.
The guardrails described under [stability classes](#stability-classes) apply to the blended score, so a model grade cannot lift a vendor out of its class either.
An override is not averaged in. See [caps and floors](#caps-and-floors) below.
0-19 Very High Risk · 20-39 High · 40-59 Medium · 60-79 Low · 80-100 Very Low.
### Two rules that shape everything
Missing features drop out and the remaining weights renormalize. The cost of sparse data is paid by the **confidence tier**, not by the score. Otherwise a poorly-covered vendor would look distressed purely for being poorly covered, which is a very expensive kind of wrong.
The same applies at the ratio level: a ratio with a zero, missing, or wrong-signed denominator is treated as *absent*, not as zero.
The rule above says sparse data must not read as distress. It does not license sparse data reading as strength.
An *observation we never made* is capped rather than scored perfectly. For a company whose filings we read, an empty adverse-event stream really does mean nothing was disclosed; for a private company it means nothing was observed, and it is scored well but not perfectly. Likewise a score resting on neither statements nor a defensible cash estimate is held below the top band.
Read together, the two rules are what keep the least visible vendors in a portfolio out of the top of the ranking.
Smoothing damps routine movement in both directions, but severe events and every override bypass it entirely. A company recovering from distress climbs gradually as the evidence accumulates; a company entering distress drops immediately.
## Peer comparison
A ratio in isolation is not a judgement. 4x debt/EBITDA is unremarkable at a utility and alarming at a software company, so every Tier A ratio is scored as a percentile inside a cohort rather than against an absolute threshold.
**The cohort is real, and it is large.** It's built from the population of filers that reported the same concept in the same period: typically thousands of companies per ratio, not a hand-picked comparison set.
**Industry narrows it.** Ranking a software vendor against every filer (banks, REITs, miners) produces a percentile that is arithmetically correct and analytically meaningless, so cohorts are scoped to the vendor's own industry classification.
**When the cohort is too small, the card says so.** The score falls back to a wider population and discloses that it did. A disclosed wide cohort is honest; an undisclosed one is misleading.
Tier B and C signal features (funding, headcount) are scored against documented absolute curves rather than peer percentiles, because no equivalent free population exists for them. Any input scored that way is flagged as not peer-ranked, both on the card and in the API.
## Caps and floors
Some facts should not be averaged. A bankruptcy filing is not a modest deduction to be offset by a healthy current ratio, so these rules apply after the weighted score and override it outright:
| When | Effect |
| - | - |
| Registration dissolved or in liquidation, or a bankruptcy filing | Score pinned at 5 |
| Going-concern doubt in an audit opinion | Capped at 30 |
| Operating status reported as closed | Capped at 15, pending review |
| Debt maturing within 12 months **and** either negative free cash flow or more than 30 months since the last raise | Capped at 45 |
Every override that fires is recorded with its reason and shown on the card, so a pinned score explains itself rather than looking like an unusually harsh weighted result.
## Adverse events
Events that bear on financial health (bankruptcy filings, going-concern doubt, mass layoffs, auditor changes, delistings, CFO departures, down rounds, material impairments, regulatory actions, late filings) are weighted by severity and decay over time.
Events awaiting human confirmation are labelled **Needs review**, and they do not move the score until they are confirmed. Dismissed events stay on the record for audit but stop affecting the number.
## What the card shows
* **A one-to-two line summary** covering what the score was built on, the stability class, and how much runway the company has
* **Score, risk band, and confidence tier**, with 3-month and 12-month movement
* **Pillar breakdown**, each with the weight it carried and the inputs behind it
* **Financial vitals**: revenue and growth, operating margin, current ratio, debt/EBITDA, interest coverage, free cash flow margin, estimated runway, total raised, headcount, last funding round
* **Registered entity standing**: status, jurisdiction, and filing compliance
* **Peer context**: the cohort the vendor was ranked inside and its percentile within it, with any fallback disclosed
* **Score history**, plotted as discrete restatements rather than a smooth line, because each point is a separate computation
* **Adverse events** with date, review status, and a link to the source that reported each one
* **Caps and floors** applied, with the reason
* **Sources**, each with the date its data was true, plus the sources that were asked for and unavailable
### Why this score?
Open the rationale on any pillar and the card shows the inputs that produced it, each with the measured value, what it scored, and how heavily it counted. Inputs are ordered by how much they cost the pillar, so the reason for a low score is at the top.
A capital position of 50 might resolve to a current ratio of 1.8x scoring 62 at half the weight, and a registration status Coverbase could not determine. That second one matters more than it looks: an undeterminable input is labelled as such rather than shown as a bare number, because "50" reads as measured mediocrity when it means nobody knows.
Two things travel with every input:
* **Whether it was peer-ranked.** An input scored against the vendor's own cohort is a much stronger claim than one scored against an absolute curve.
* **The date the value was true.** Filed figures lag. An input from a filing two quarters old carries its own as-of date, not the date of the refresh.
## Submitting a vendor's own financial statements
Most vendors are private companies, so most score Tier C however sound they are: there is nothing filed to read. If you already hold that vendor's financials -- and in a diligence relationship you usually do -- you can give them to Coverbase and the score is rebuilt on them.
**Vendor Intelligence > Financial**. **Upload financial statements** sits in the page header, between **Refresh** and **Export**. **Upload supporting information** in the actions menu (**...**) opens the same dialog. When the window is too narrow, **Upload financial statements** moves into that menu too.
Audited financials, tax returns, SEC filings, management accounts. Supporting evidence belongs here too -- a Dun & Bradstreet report, a Better Business Bureau profile, a consumer report. Coverbase reads those for the entity's identity and for concerns, and will not invent fiscal periods from them. **Link existing documents** adds files already on the vendor's Documents tab without uploading them again.
**Generate analysis** runs it. Uploading and generating are separate on purpose -- you can add files across several sessions and run the analysis when the set is complete. One pass reads every document together, because a statement set only makes sense as a set. It takes a few minutes; the tab shows progress and says plainly if a document could not be read.
### Exporting the analytics workbook
Once an analysis exists, **Export analytics workbook** in the tab's overflow menu downloads the full credit spreadsheet: the memo and review summaries, every metric beside the two figures it was computed from, the raw line items with the page each was read from, and the reference sheets that define what Low, Medium and High mean.
It is offered only where an analysis exists -- the workbook is a rendering of one, and there is no such thing as an empty one. Nothing in it is inferred: the credit agency and reputational rows say **Not established** rather than deriving an agency rating from a statement set.
### Changing what the analysis reads
Both the upload dialog and the **Documents used in this analysis** list on the tab let you take a document out of consideration. The file stays on the vendor's Documents tab -- excluding it from a financial analysis is not a reason to delete it.
Removing or adding a document does not blank the figures already on screen. They are still true of the documents they were computed from, so Coverbase keeps them and marks the analysis stale: the tab says the document set has changed and offers **Regenerate**. Nothing is recomputed, and nothing is charged, until you ask for it.
### What you get back
The classification and audit opinion, the periods covered, the issuing legal entity and its auditor, and the full metric battery per fiscal year with the change between years:
* **Balance sheet** -- working capital, current ratio, quick ratio, cash ratio, total funded debt, debt to equity, debt to capitalization, net worth, asset turnover, return on assets, equity multiplier, return on equity
* **Income statement** -- revenue, EBIT, EBITDA, degree of financial leverage, debt to EBITDA, gross and operating margins, net income, net income margin, earnings per share, inventory turnover, AR turnover
* **Cash flow** -- free cash flow, change in cash
Plus a credit-policy risk rating on the four metrics policy rates a partner on -- EBITDA, debt to EBITDA, free cash flow and net worth -- and an overall rating that takes the worst of them, because a partner is only as strong as the metric policy is most worried about.
The tab shows the headline of this. The full tables are available to [assessment report templates](/reporting/template-placeholders#submitted-financial-statements), which is where a credit memo has room to print them.
### How the figures are produced
The model reads the statements and reports **line items** -- figures that appear on a balance sheet, an income statement or a cash flow statement, each with the page it came from. Every ratio, every year-over-year change and every risk rating is then computed by Coverbase, not by the model. A credit memo's arithmetic has to be reproducible from its inputs, and a model asked to divide two numbers is occasionally wrong and always sounds certain.
A figure the statements do not report comes back as **not reported**, never as zero. A zero is a measured result and reads as one.
**Submitted statements are private to your organization.** They never reach the shared company record, so no other Coverbase customer sees them or the score built on them. The vendor's published score -- the one every other organization sees -- is unchanged. Withdrawing the analysis restores your view to that published score and leaves the documents on the vendor's Documents tab.
## Where it appears
The **Coverbase Financial Health Score** card, refreshed on the regular Vendor Intelligence cadence. The **Financial** tab opens the same data full width, with score history, every pillar expanded to its inputs, the full vitals set, and the event timeline.
Financial facts are supplied to control evaluations as authoritative evidence, ranked ahead of web results.
A new vendor request is scored against its registered identity and financial standing before the web is consulted.
Available on the vendor fact-sheet endpoint as `financials.financial_health`, and conversationally through MCP: "what's the financial health score for Acme?"
## Coverage and limits
Coverage is honest about its edges, and these are the ones worth knowing before you build a process on the score.
* **SEC EDGAR covers roughly 7,000 US filers**, often 15-25% of a typical vendor portfolio, on a quarterly cadence with a 40-90 day filing lag. Many private vendors will sit at Tier C, and that is the system working as designed rather than failing.
* **Tier B and C scores are inferred.** They rank vendors sensibly against each other. They do not carry statement-level precision, and the confidence tier is how you tell.
* **Runway is a bound, not a measurement.** The priors behind it are reasoned from what is typical of software companies, not fitted to observed outcomes. Use it to rank and to prompt a question, never as a figure to quote back to the vendor.
* **A stability floor can mask weakness.** An incumbent whose fundamentals are deteriorating, but which has triggered no hard rule, will not read worse than its class floor. That is a deliberate trade against the opposite failure, and it is why the class and any adjustment are published beside the score rather than applied silently.
* **The score is a ranking, not a probability.** The weights are heuristic, chosen to order vendors sensibly rather than fitted against observed failures. Treat the score as "who needs attention first", not as an estimated probability of default.
* **Headcount and funding data lag** and skew toward venture-backed technology companies. A bootstrapped logistics vendor may barely register in them.
* **A scorecard built on one or two signals is capped mid-scale.** Most of such a score comes from an adverse-events pillar that found nothing because nothing was watched, so it reports what it found without reading as reassurance. The cap is published beside the score.
* **Trend features need history.** Where a source publishes only current values, trend inputs are omitted until Coverbase has two snapshots of its own. They are never assumed flat.
* **The score describes the entity that was matched.** If a vendor is a subsidiary and the filings belong to the parent, the score describes the parent's balance sheet. The Corporate Registration card shows which legal entity was bound. See [Vendor Intelligence](/products/vendor-intelligence).
Adverse events are limited to what regulatory filings disclose.
## Availability
The Financial Health Score is an optional feature, enabled per organization. **Contact your Coverbase representative to have it turned on.** Nothing is computed or stored for an organization that doesn't have it enabled.
It pairs with [Vendor Intelligence](/products/vendor-intelligence), which validates the corporate identity the score is computed against, and [Security Intelligence](/products/security-intelligence), which rates a vendor's external security posture. For reading the card day to day, see the [financial health and security intelligence guide](/user-guides/vendor-fact-sheet).
# Findings Manager
Source: https://docs.coverbase.com/products/findings-manager
Intelligence layer over findings across every assessment: remediation tracking and systemic risk pattern detection.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Findings Manager sits on top of the issues raised across all of your assessments. Rather than treating each finding as an isolated to-do, it tracks remediation outcomes over time and surfaces the systemic patterns that span vendors, control sets, and risk domains, so recurring weaknesses become visible instead of being closed one ticket at a time.
## What it does
Roll up findings from every assessment, and from documents, contracts and Radar, into a single view grouped by vendor, control set, assignee or risk level.
Track each finding from open through remediation and verification, including vendor commitments, owners, due dates, and time-bound risk acceptances.
See recurring weaknesses across the portfolio by grouping on control set or vendor: the same control failing across many vendors, or one vendor repeatedly missing the same requirement.
Score findings by severity and urgency, or set the risk level directly, and let the risk level set the due date so reviewers spend time on the findings that matter most.
## How to integrate
List, create, retrieve, and status-sync findings programmatically across assessments and vendors.
Pull findings into your GRC platform, ticketing system, or executive dashboards for remediation reporting.
Ask about findings conversationally. "Which open findings are tied to encryption controls?" or "Show me every vendor with an overdue remediation."
Subscribe to `Finding.*` events and react when findings are created, updated, or resolved.
## Common workflows
Save a filtered view of related findings (for example, every vendor missing a data-breach notification commitment), assign owners, request commitments per vendor, and track closure together rather than as scattered tickets.
Feed aggregated findings into executive and board reporting. Highlight the controls that fail most often across the portfolio so investment goes where it reduces the most risk.
Sync findings to Jira, ServiceNow, or your issue tracker via the Export API and webhooks, keeping remediation work where your teams already operate while Coverbase remains the system of record.
Findings are surfaced through the [Findings API](/api-reference/findings), the [Export API](/export-api-concepts), and the [MCP server](/mcp/overview). They are raised from the issues [Assessment Copilot](/products/assessment-copilot) finds, and from documents, contracts, Radar and other product surfaces. How to work them is in [Findings and remediation](/user-guides/findings-and-remediation).
# Front Door
Source: https://docs.coverbase.com/products/front-door
Triage every intake request before due diligence starts: is the vendor new, can earlier due diligence be reused, does the request need an inherent risk questionnaire, and is the vendor on the Do Not Use list.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Front Door is the first review an intake request gets. Before anyone sends a questionnaire or opens an assessment, the TPRM Office answers four questions on one page: is this a new vendor or one you already have, is there an engagement whose due diligence can be reused, does the request need an inherent risk questionnaire (IRQ), and is the vendor blocked. The answers are recorded as a **disposition**, signed off by two people, and kept in the request's audit trail.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
![Front Door tab for Orbitline Data Services showing a deterministic D-U-N-S and LEI match, a similar engagement inside the 12-month reuse window, a reuse proposal for eight risk domains, and a decided disposition signed by the TPRM Office and Supply Chain]()
## What it does
Matches the request against your vendors on tax ID, D-U-N-S number and LEI, which count as deterministic, and on domain and name, which count as probabilistic. Tax IDs stay sealed: Coverbase shows only the last four characters.
Finds the most similar existing engagement by shared services and tags, says whether its completed due diligence is inside your reuse window (12 months unless you change it), and proposes per risk domain whether to reuse it, run an abbreviated review or start again.
A disposition is decided only when one person from the TPRM Office group and a different person from the Supply Chain group have both signed it off. Revising it clears both sign-offs.
While a disposition waits for sign-off, a member of a group that has not signed yet can decline it with a required reason. The disposition goes back to the TPRM Office as a draft, any sign-off already given is cleared, and the TPRM Office and the requester are notified.
Rules read the intake answers and decide whether an IRQ is required and which templates to send. The required IRQs go to the requester once, as soon as the disposition is decided.
A vendor marked Do Not Use can still be requested, but the requester is warned and approving the request needs an override rationale. Adding a vendor to the list and taking it off both need a reason.
When a request started as a purchase requisition in a connected procurement system, the review shows where it came from, its value and category. With budget lines synced, it shows the request's draw against the line and any budget exception the requester asked for.
With Teams approvals on, both sign-off groups can sign off or decline from one Teams card. A decision made in Coverbase updates that card, so it cannot record a second decision.
## How reuse works
A disposition takes one of three forms:
| Disposition | What happens next |
| - | - |
| **Add as new engagement, reuse due diligence** | The vendor's next assessment launched from an assessment plan drops the control sets for every domain marked **Reuse prior due diligence**, copies the prior assessment's scores for those domains, and labels each copied score with the assessment it came from. |
| **Extend the existing engagement** | The request is treated as an amendment to an engagement you already have. No new engagement is created. |
| **Full new due diligence** | Prior results are ignored and due diligence runs in full. |
A reuse decision is applied once, to the next plan-launched assessment for that vendor. Zero Touch assessments do not consume it. After it has been applied, nobody can revise it, and the engagement record shows which domains reused diligence satisfied. If someone scores a reused domain on the new assessment, Coverbase removes the reused label from that domain.
## When a sign-off group declines
While a disposition waits for sign-off, a member of a sign-off group that has not signed yet can click **Decline**, beside **Approve triage**, and write the reason. A decided disposition cannot be declined. Coverbase then:
* returns the disposition to the TPRM Office as a draft and clears any sign-off already given,
* shows on the disposition who declined, for which group, and why, and records the same in the audit trail,
* notifies the TPRM Office and whoever recorded the disposition with the reason, and tells the requester that the TPRM Office is revising the decision.
Nobody can sign off or decline again until the TPRM Office records the disposition again. Recording it again clears the decline and asks both groups to sign off.
![Disposition card labeled Back with the TPRM Office, with a notice that Dana Sato declined for Supply Chain because the hosting region is not in the request, a Record again button, and the decline entry in the audit trail]()
## What it does not do
* It does not approve the vendor. Approving the intake is still a separate step, and a vendor created through intake stays in its created status until someone moves it.
* It does not decide on a name match alone. A domain or name match is shown as probabilistic, and only a registry identifier counts as deterministic.
* It does not remove a vendor from the Do Not Use list when an override is recorded. The override applies to that one request.
## Where to go next
Set up the reuse window, sign-off groups and IRQ rules, then triage a request step by step.
Where reused and new diligence come together for the Transaction Owner.
How a request is filed in the first place, from the portal, the API or an AI assistant.
How the IRQ the Front Door sends is scored and who reviews each domain.
# Intake Agent
Source: https://docs.coverbase.com/products/intake-agent
Zero-form intake: requesters ask for a new vendor in Slack, Microsoft Teams, email or their AI assistant, and the Intake Agent fills in what their words say, names approved vendors already doing similar work, asks only for what is missing, and opens the intake for the Front Door.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Your Coverbase representative turns on the third-party lifecycle features, including the Intake Agent, for your organization.
Most people who need a new tool will not fill in a form until they are made to. The Intake Agent meets them where they already ask: a direct message to the Coverbase app in Slack, a chat with your Coverbase bot in Teams, an email to your intake inbox, or their AI assistant through the [MCP server](/mcp/vendor-intake). It reads what they wrote, works out what it can, asks for the rest in the same thread, and opens an ordinary intake request that the [Front Door](/products/front-door) triages like any other.
![Intake Agent page with Slack and Microsoft Teams channels marked Needs setup, Email and AI assistants marked Ready, each with an Off switch, and an empty Conversations table]()
## What it does
* **Reads the request.** One model call per message works out the vendor, what it is for, the kinds of data it touches (from a fixed list, including **No company data**) and short category terms. Each call is recorded in the [Agent Ledger](/products/agent-ledger).
* **Matches the vendor in code.** An exact name or domain match on one vendor is that vendor. A name matching several vendors is a question to the requester, listing them, and "new" is an answer. No match means a new vendor, created when the intake opens. The model never picks a vendor record.
* **Names similar approved vendors.** Vendors already approved whose use case shares the request's terms are listed in the reply, so the requester and the TPRM Office can reuse before buying. They never block the request.
* **Asks only for what is missing.** If the vendor, the purpose or the data is unclear, the agent replies with what it understood and a numbered question for each gap.
* **Opens the intake.** With everything known, it opens the intake on the same path as the Intake API, with the requester as the requester, your portal's questionnaires, and the conversation as context, starts drafting answers, and replies with the link.
## Who can use it
Only active members of your organization open intakes. Slack checks the member's confirmed address in your installed workspace, Teams the address Microsoft's roster returns for the sender, and email that the sender is a member and that the message passed SPF, because an inbox address is public. MCP uses the signed-in user, with the confirmation every MCP write needs.
## Guardrails
* A channel your organization left off takes nothing, and Slack and Teams requesters are told so.
* A message delivered twice is stored once.
* After five messages with something still missing, the agent stops and points the requester to the intake form.
* Once a conversation opens its intake, the next message in the same thread starts a new request.
## Where to go next
Turn on each channel and follow the conversations.
What happens to the intake next.
The portal and API ways in.
Registering the bot the Teams channel uses.
# Integration Hub
Source: https://docs.coverbase.com/products/integration-hub
Two-way sync with your procure-to-pay and contract lifecycle systems (Coupa, SAP Ariba, Ironclad, Icertis), findings and vendor risk pushed to GRC and ERM tools (Archer, ServiceNow IRM, a REST risk register), Microsoft Teams notifications and approvals, and the Intake Agent, with field mappings, a sync log and a steward queue for suppliers that do not match.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Your Coverbase representative turns on the third-party lifecycle features, including the Integration Hub, for your organization.
The Integration Hub connects Coverbase to the systems your purchases and contracts already move through. Requisitions in your procurement system open intake requests, supplier records link to your vendors, executed contracts in your contract lifecycle system mark the Coverbase contract executed, and Coverbase writes its risk tier, approval status and contract risk back to the provider. Every connection has **Field Mappings**, **Sync Log**, **Steward Queue** and **Authentication** tabs.
## Providers
| Provider | Category | Direction | What syncs |
| - | - | - | - |
| [Coupa](/integrations/guides/coupa) | Procure-to-pay | Two-way | Requisitions, suppliers, contracts and budget lines in; supplier risk tier and approval status, and contract risk rating, out |
| [SAP Ariba](/integrations/guides/sap-ariba) | Procure-to-pay | Inbound only | Supplier master data with qualification status, and sourcing events |
| [Ironclad](/integrations/guides/ironclad) | Contract lifecycle | Two-way | Records and their signed copies in; risk rating, required clause pack and blocking issues out |
| [Icertis](/integrations/guides/icertis) | Contract lifecycle | Two-way | Agreements and their executed copies in; risk rating, required clause pack and blocking issues out |
| [Archer](/integrations/guides/archer) | GRC and ERM | Two-way | Findings as issues and vendors as risks out; each record's status back |
| [ServiceNow IRM](/integrations/guides/servicenow-irm) | GRC and ERM | Two-way | Findings as GRC issues and vendors as risks out; each record's state back |
| [ERM risk register](/integrations/guides/erm-register) | GRC and ERM | Outbound | A risk per rated vendor, to a REST register you describe |
| [Microsoft Teams](/integrations/guides/microsoft-teams) | Messaging | Outbound, plus card actions | Notifications you choose, posted to a channel as Adaptive Cards; with your bot, approvals from the card and intake chats |
## How a sync works
Each connection syncs on its own interval (every 60 minutes unless you change it, and no more often than every 15 minutes), and on demand with **Sync now**. A provider that can call a webhook can also nudge a sync when a record changes. A webhook from a contract lifecycle system that names a contract syncs only that contract, including a contract whose record ID is `0`. Inbound passes run first, in a fixed order, so later passes can find suppliers through links the supplier pass made:
1. **Suppliers** link to a vendor and record its approved supplier list status.
2. **Requisitions and sourcing events** open a draft intake request carrying the value, category and requester, and pass the supplier's tax ID, D-U-N-S number and LEI to the Front Door.
3. **Contracts** create or update a Coverbase contract and, when executed in the provider, mark it executed through the same path DocuSign uses, so the executed notice and accounting packet fire the same way.
4. **Budget lines** (Coupa) record the amount and committed spend that Spend Controls and the intake budget step read.
Outbound runs last, and pushes a record only when its values changed since the last push. After the push, an Archer or ServiceNow IRM connection reads back the status of every issue and risk record it holds. Coverbase stores that status and does not change the finding's own status from it. Each record is written on its own, so one bad record fails alone, and the sync log says which record failed and why.
![Sync Log table with a scheduled run marked Partial, a webhook run marked Succeeded, and a manual run marked Failed because the provider rejected the stored credentials]()
## Matching suppliers
A name alone never links a supplier. A tax ID, D-U-N-S number or LEI match links on one hit, and a domain links only when no stronger identifier points to a different vendor. Every match is among your organization's own vendors. Anything else goes to the **Steward Queue**, where someone links it to the right vendor or dismisses it. Once linked, a supplier is never re-matched. The queue filters by system, reason, age and name, and links or dismisses many records at once as a background job that reports, for example, "12 linked, 3 need a decision". A contract that arrives before its supplier is linked waits, and is filed against the vendor, with its executed copy, as soon as the steward links the supplier.
![Steward Queue table listing four Coupa supplier records with reasons Several matches, Identifiers disagree and No match, each with a vendor picker and Link and Dismiss buttons]()
## Approvals in Teams
With a Coverbase bot registered in your Azure tenant, the Microsoft Teams connection posts three requests with **Approve** and **Decline** buttons: a Front Door disposition waiting on a sign-off group, a finding's acceptance chain waiting on a decision, and exit plan evidence waiting on its approver. People decide in Teams as themselves, with their own Coverbase permissions. A Front Door card is posted once for both sign-off groups and is replaced with the outcome whether the sign-off or decline happens on the card or in Coverbase. See [Microsoft Teams](/integrations/guides/microsoft-teams).
## The required clause pack
The clause pack written to a contract lifecycle system lists the high and critical severity clauses of your active clause sets, up to 25, by clause ID and name. It is the same list for every contract. Blocking issues are the titles of the vendor's open findings, up to 20.
This list is the same for every contract written to a contract lifecycle system. The clauses a particular engagement requires, from its own risk results and open issues, are its [clause pack](/products/clause-pack), shown on the engagement's **Contract** tab.
## Credentials and webhooks
Credentials go to a secrets manager when you save them and are never returned. The page only says which fields are set. A connection's webhook signing secret is shown once, when you create or rotate it. Inbound webhooks must be signed (see [Integration credentials and signing](/security/integration-credentials#inbound-integration-webhooks)), and a webhook body is never trusted as data: it only starts a sync that re-reads the record from the provider.
## Where to go next
Connect a provider, review its field mappings, read the sync log and work the steward queue.
Where a synced requisition shows up for the TPRM Office.
Everything Coverbase connects to, and which systems have a connector.
How credentials, signing secrets and webhooks are protected.
# Internal control monitoring
Source: https://docs.coverbase.com/products/internal-controls-monitoring
Coverbase against your own applications: evidence collected from live admin consoles, 392 internal controls out of the box, drift detection between runs, and internal findings sharing the same findings, workflow and reporting machinery as third-party risk.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Most risk platforms make you run two programs: one for your third parties and one for yourself, in different tools, with different evidence, different findings and different reporting. Coverbase runs both on the same objects.
The third-party half is what Coverbase is best known for. This page is about the other half: evaluating the controls inside the applications **you** run, on the same control model, feeding the same findings, workflows, dashboards and audit trail.
Internal control monitoring is delivered by [Coverbase Inspect](/products/agentic-inspect) and is enabled per organization. If you do not see **Inspect** in your navigation, ask your Coverbase team to switch it on.
## Evidence read from the admin console
Traditional compliance evidence collection is a screenshot request. Someone is asked whether MFA is enforced, they open the admin console, they screenshot it, they paste it into a ticket, and a quarter later nobody knows whether it is still true.
Inspect signs in to the application tenant with **read-only** credentials and reads the answer off the live admin console itself, then records what it saw with chain-of-custody metadata: the screenshot, the source URL, the timestamp, and the request context.
The inspection identity holds a read-only role inside each target application. Authentication and authorization are separate concerns: your identity provider authenticates the inspection identity, and the target application's own read-only role is what bounds it.
An observation that could not be obtained still exists and still says why: unsupported, authentication required, forbidden, inconclusive, or failed. An application that does not sell a capability is not marked down for lacking it.
Each control gets its own run, so one control failing to collect evidence never stops the rest of the set.
**Explore** establishes whether the evidence can be collected at all. **Evaluate** adjudicates it against the control expectation and your scale. Progress and outcome stay separate facts.
## 392 internal controls, ready to run
The [Internal Controls Library](/control-library#internal-controls-library) ships **22 templates spanning 392 controls**, so a program does not start from a blank control set.
| Area | Templates |
| - | - |
| Baseline | Security Configuration Baseline |
| Identity and access | Identity & Authentication Baseline, Privileged & Administrative Access, Application Access Lifecycle |
| Scope | Application Scope & Feature Drift, Integrations, OAuth & Connected Apps |
| Data | Data Services & Storage Surface, PII Data Scope & Handling, Retention Residency & Deletion, Export Sharing & External Collaboration |
| Regulated data | PHI & HIPAA Application Safeguards, GDPR & Cross-Border Privacy |
| AI | AI Features & Model Usage, AI Agents Copilots & Autonomous Actions |
| Resilience | Operational Resilience & Failover, Performance & SLA Conformance, Audit Logging & Monitoring |
| Commercial | Usage Seats & Licensing |
| Application classes | CRM Application Controls, HRIS & Payroll Application Controls, Financial Services Application Controls |
| Framework-derived | CIS Controls v8.1 SaaS Baseline, citing the CIS safeguard and the NIST SP 800-53 controls behind each control |
Each control states an expectation carrying its own threshold, names the admin surface that answers it plus the alternate labels different vendors use for the same screen, and defines what counts as incomplete. Fork a template and it becomes your control set, fully editable, exactly like a vendor framework.
## Drift between runs
Point-in-time evidence decays the moment an administrator changes a setting. Inspect's **Drift** mode compares a run against a compatible earlier one and reports what moved.
* **Outcome** is `exact`, `changed`, or an explicit reason it could not be compared, never a silent pass.
* **Materiality** is judged on a change: material, immaterial, or inconclusive, with a summary of what differs. A renamed label is not the same event as a disabled control.
* **Re-run on a cadence you choose**, so "is MFA still enforced on the finance system" is a question your evidence answers this week rather than last audit.
A material change emails the person who started the inspection, or who owns its schedule. To track it to closure, run **Evaluate** and create a finding from the control, which then has an owner, a due date and the same workflows and dashboards as third-party findings.
## One risk model, both sides
This is the part that matters for an enterprise risk view. Internal and third-party risk are not parallel systems in Coverbase; they are the same system pointed at two populations.
| Shared object | Internal | Third party |
| - | - | - |
| **Control sets** | Internal Controls Library, forked and edited | Vendor Controls Library: SOC 2, ISO 27001, NIST, PCI, the Interagency Guidance, and 60-plus more |
| **Evaluations** | Read from your admin consoles | Read from vendor evidence, attestations and questionnaires |
| **Risk domains** | The same domains, so an identity weakness scores in the same place whoever owns it | Same |
| **Risk scales** | Your scale | Your scale |
| **Findings** | Assigned, tracked, escalated, closed with evidence | Same objects, same queue |
| **Workflows** | Same trigger, condition and action engine | Same |
| **Reviews and approvals** | Same gates, same outcomes, same attribution | Same |
| **Dashboards and reporting** | Same charts, filtered by population | Same |
| **Audit trail** | One trail | One trail |
The practical consequence: a single dashboard can show that your own privileged-access control is weak **and** that three critical vendors have the same gap, scored on the same scale, in the same risk domain. Answering that across two separate systems normally means exporting both into a spreadsheet.
Start with the applications that already carry your regulated data. Inspect the identity provider, the CRM, the HRIS and the finance system against the Identity & Authentication Baseline and Privileged & Administrative Access sets. Those four applications and two control sets usually surface more than the first year of a manual internal control program does.
## Compliance evidence automation
Where an internal audit or a compliance program needs evidence on a schedule rather than a request:
Fork the internal templates that match your framework, edit expectations to your thresholds, and attach them to the applications in scope.
Evidence is gathered from the live console, with the screenshot, source and timestamp attached to each observation. Nobody is asked for a screenshot.
Evaluate produces the judgment against your scale. Create a finding from any control whose evaluation raised an issue, and it gets an owner, a due date and a workflow behind it.
Subsequent runs compare against the baseline. A material change sends an alert; an immaterial one is noise that does not reach anyone's inbox.
The same [evidence packaging](/reporting/due-diligence-file) that produces a third-party due-diligence file produces the internal control evidence package, with the audit trail behind it.
## Related
The inspection engine itself, and the vendor-facing half of it.
Every internal and vendor control set, with counts and sources.
The shared findings and remediation surface.
How both halves map to banking supervisory expectations.
# License and accreditation
Source: https://docs.coverbase.com/products/license-and-accreditation
How Coverbase decides which licenses a vendor needs, which public registers it searches for them, and how it reports every register it checked.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
A vendor that collects debts, originates mortgages, adjusts claims or rewires a building usually needs a license from the state or country where it works. The license lives on the issuing regulator's own register, not on the vendor's website. Coverbase works out which licenses the vendor's business calls for, searches the registers that issue them, and shows you what each register says.
Sanctions and debarment lists are not part of the license lookup: the Zero Touch sanctions screen checks the vendor against them separately. Enforcement actions and exclusions the license lookup finds are shown first.
The most common mistake is reading an empty result as a clean one. A register that was not read, or that publishes no lookup, says nothing about the vendor. The page lists every register planned for the vendor and what happened at each one, so you can tell the two apart.
## Where it runs
The **Licenses** tab of a vendor's [Vendor Intelligence](/products/vendor-intelligence) section. License records are gathered with the corporate registration research and refresh with it. Refreshing that research checks the registers again.
A [Zero Touch](/products/zero-touch-assessments) run that includes the **Licenses** section (on by default) waits for the vendor's license research, then grades the license controls from the same records the **Licenses** tab shows.
Research waits for a description of the vendor. Until the vendor has an industry or a description on file, nothing is stored, because registers chosen from nothing would read as "no license register applies".
## How a lookup runs
```mermaid theme={null}
flowchart LR
A["Vendor description and headquarters"] --> B["Lines of business, states and countries"]
B --> C["Plan: the register for each line in each jurisdiction, plus entity, enforcement and exclusion registers"]
C --> D{"Register"}
D -->|"Searchable"| E["Search under up to 3 spellings of the vendor's names"]
D -->|"Not read automatically"| F["Lookup link and the reason"]
D -->|"No license there, or no public lookup"| G["Noted on the list of registers"]
E --> H["Keep records that match the whole name; enforcement and exclusion lists need the exact legal name"]
H --> I["Records and registers checked, on the Licenses tab and in the Zero Touch review"]
F --> I
G --> I
```
A model reads the vendor's name, headquarters and description the way a reviewer would, and names every licensed line of business the vendor itself is in. It judges the vendor's own activity, never its customers': a consulting firm that serves banks is not a bank, and software, data, research and consulting need none of these licenses. When the description does not say what the vendor does, it chooses none and says the description is too thin. Its one sentence of reasoning is kept and shown when no register applies.
The same read gives the US state of the headquarters, the US states the description confines the vendor to (a local practice, a regional bank, "licensed in Texas and Oklahoma"), whether it serves the US nationwide, and the countries outside the US where it is headquartered or operates. A US vendor that names no states is searched in every state, because licensed firms rarely list them.
For each line of business, the plan takes the register that licenses it in each state and the national register for that line. It adds the business entity filing in the headquarters state, financial enforcement lists when a line is financial, Medicaid exclusion lists when a line is in health care, and the company registry and financial regulator of each country outside the US. Sanctions lists and SEC filing indexes are never planned, because they hold no license.
Each register is searched by business name under up to three spellings of the vendor's names. A register gets 30 seconds, the whole lookup gets 150 seconds, and Coverbase sends at most three searches at a time to any one register's site.
A register's search returns every firm that shares a word with the query. Only records that match the vendor's whole name are kept. See [How records are matched](#how-records-are-matched).
Every planned register lands on the **State and National Registers** list with its outcome. A register that was not searched automatically carries a **Look up** link and the reason, so you can check it yourself.
## Supported lines of business
The classifier chooses from the lines below. A category applies in every country: an HVAC installer in Australia is a specialty contractor, and a recruiter in India is staffing or PEO.
| Category | The vendor... |
| - | - |
| **Investment or securities** | Manages money, gives investment advice, or brokers or deals securities |
| **Bank charter** | Is a chartered bank, trust company or credit union |
| **Mortgage lender** | Originates or brokers residential mortgage loans |
| **Mortgage servicer** | Services mortgage loans for others |
| **Money transmitter** | Transmits money, sells payment instruments or stored value, or exchanges virtual currency for customers |
| **Consumer lender** | Makes consumer, installment, payday or small loans |
| **Debt collector** | Collects consumer or commercial debts owed to others |
| **Debt buyer** | Buys charged-off debt and collects it |
| **Check casher** | Cashes checks or offers deferred deposit |
| **Sales finance** | Finances or buys retail installment contracts (auto or goods) |
| Category | The vendor... |
| - | - |
| **Insurance carrier** | Underwrites insurance as an insurer or reinsurer |
| **Insurance agency** | Sells, solicits or negotiates insurance as an agency or broker |
| **Insurance adjuster** | Adjusts insurance claims as an independent or public adjuster |
| **Title agent** | Is a title insurance agency |
| **Title insurer** | Underwrites title insurance |
| **Escrow agent** | Holds escrow for real estate or other transactions |
| **Premium finance** | Finances insurance premiums |
| **Third-party administrator** | Administers insurance or benefit plans for insurers or employers |
| **Surplus lines broker** | Places surplus lines insurance |
| Category | The vendor... |
| - | - |
| **Real estate brokerage** | Brokers, lists or leases real estate for others |
| **Appraisal management** | Is an appraisal management company |
| **Appraisal firm** | Performs real estate appraisals itself |
| **Auctioneer** | Auctions property |
| **Property management** | Manages rental property for owners, including property preservation |
| **Community association management** | Manages HOAs or community associations |
| **Home inspection** | Performs home inspections |
| **Foreclosure trustee** | Acts as trustee in non-judicial foreclosures |
| Category | The vendor... |
| - | - |
| **General contractor** | Builds, repairs or renovates commercial work |
| **Residential contractor** | Builds, repairs or renovates residential work |
| **Specialty contractor** | Performs trade work such as electrical, plumbing, HVAC or roofing |
| **Lead and asbestos abatement** | Performs lead or asbestos abatement |
| **Mold remediation** | Performs mold remediation |
| **Pest control** | Performs pest control |
| **Locksmith** | Performs locksmith work |
| Category | The vendor... |
| - | - |
| **Public accounting** | Is a CPA firm offering audit, attest or tax services |
| **Legal practice** | Is a law firm |
| **Engineering firm** | Offers engineering services |
| **Architecture firm** | Offers architecture services |
| **Surveying firm** | Offers land surveying services |
| **Private investigation** | Offers private investigation |
| **Security guard services** | Offers security guard services |
| **Process server** | Serves legal process |
| **Alarm systems** | Installs or monitors alarm systems |
| Category | The vendor... |
| - | - |
| **Pharmacy** | Dispenses drugs |
| **Drug wholesale distribution** | Distributes or warehouses drugs |
| **Health facility** | Operates a licensed health facility |
| **Healthcare provider** | Bills Medicaid or Medicare for care it provides |
| Category | The vendor... |
| - | - |
| **Motor vehicle dealer** | Sells vehicles |
| **Vehicle title service** | Processes vehicle titles and registrations |
| **Salvage vehicle auction** | Auctions salvage vehicles |
| **Electronic lien and title** | Provides electronic lien and title services to lenders and DMVs |
| **Waste hauler** | Hauls waste |
| **Cannabis** | Operates in cannabis |
| **Staffing or PEO** | Supplies staff or acts as a professional employer organization |
| **Charitable solicitation** | Solicits charitable donations |
| **Cloud service provider** | Sells cloud services to state governments |
| **Diversity certification** | Says it is certified as minority, women or disadvantaged owned |
| Category | The vendor... |
| - | - |
| **Energy supplier** | Supplies retail energy |
| **Telecom carrier** | Provides telecom service |
A category is chosen only for an activity the description states or the company's name plainly carries. The classifier never adds the lines a company of that kind usually has: a bank is **Bank charter**, plus mortgage lending or insurance only when the description names them.
Research stored before these lines existed may show a broader category, such as **Mortgage lending or money transmission**, **Insurance, title or escrow** or **Contracting or property services**. Each is searched as every line it covers.
## The registers behind each line
Coverbase's register catalog was researched register by register: about 1,250 licensing, entity, enforcement, exclusion and certification registers across all 50 states, DC, Puerto Rico, Guam, the US Virgin Islands, federal agencies, international bodies and 17 other countries. About 600 of them are searched automatically. Every other one still appears on the vendor's list of registers with a link to its lookup.
A few examples from each family:
| Family | Example registers |
| - | - |
| Financial services | NMLS, the national register for state mortgage, money transmitter, consumer finance and debt licenses; state banking and financial regulators such as the New York Department of Financial Services, the California Department of Financial Protection and Innovation and the Texas Department of Banking; FDIC BankFind; the SEC's Investment Adviser Public Disclosure and broker-dealer list |
| Insurance, title and escrow | State insurance departments such as the California and Texas Departments of Insurance; the NAIC State Based Systems license lookup |
| Real estate and appraisal | The Appraisal Subcommittee's national registry of appraisal management companies; state real estate and appraiser boards such as the Texas Real Estate Commission; the Florida Department of Business and Professional Regulation |
| Contractors and trades | State contractor boards such as the California Contractors State License Board, the Washington Department of Labor and Industries and the Texas Department of Licensing and Regulation |
| Professional services | NASBA CPAverify for CPA firms; state engineering, architecture and surveying boards such as the Texas Board of Professional Engineers and Land Surveyors; the New York Office of the Professions; California's Bureau of Security and Investigative Services |
| Health care | State boards of pharmacy such as the Texas State Board of Pharmacy; state health facility registers such as the New York Department of Health; CMS laboratory and home health records |
| Vehicles | State DMV dealer lists such as the Texas Department of Motor Vehicles; state electronic lien and title provider lists |
| Commerce and government programs | FMCSA operating authority for waste haulers; the California Department of Cannabis Control; the IRS list of certified PEOs; state charity registries such as the California Attorney General's Registry of Charities and Fundraisers; FedRAMP, GovRAMP and TX-RAMP for cloud providers; SBA certifications and state MWBE programs |
| Telecom and energy | State utility commissions such as the Public Utility Commission of Texas, the California Public Utilities Commission and the New York Public Service Commission; FCC registration and Form 499 filer records |
These are read for every vendor whose lines or location call for them:
| Register family | When it is read | Examples |
| - | - | - |
| **Business entity filings** | Every vendor with a US headquarters, in its headquarters state | State business entity registers such as the Delaware Division of Corporations and Florida's Sunbiz |
| **Enforcement actions** | When any line is financial, in each state planned and nationally | OCC, Federal Reserve Board, SEC administrative proceedings and litigation releases, CFPB, FinCEN; state regulators' enforcement orders such as the New York Department of Financial Services |
| **Exclusion lists** | When any line is in health care, in each state planned | State Medicaid exclusion lists such as New York's Office of the Medicaid Inspector General and California's Medi-Cal Suspended and Ineligible Provider List |
| **Company registries and financial regulators abroad** | For each country outside the US where the vendor is headquartered or operates; the financial regulator when a line is financial | UK Companies House, the FCA Register and the ICO data protection register; Australia's ASIC, ABN Lookup and AUSTRAC; Corporations Canada and the Canadian Securities Administrators' national registration search; Germany's Handelsregister and BaFin; Singapore's ACRA and MAS; India's RBI and SEBI; Ireland's Companies Registration Office and Central Bank |
The countries with a planned company registry are Australia, Brazil, Canada, France, Germany, Hong Kong, India, Ireland, Israel, Japan, Luxembourg, Mexico, the Netherlands, the Philippines, Singapore, Switzerland and the United Kingdom.
## How records are matched
A register's search is a loose text search, so it returns every firm that shares a word with the query. A record is only the vendor's when its whole name is one of the vendor's names.
**Which names are searched.** The vendor's name, its aliases, every name your organization gave the vendor (often the legal name, such as "Example Holdings, LLC" for the brand "Example"), and the official name from the vendor's corporate registration match. The registration name is left out when it comes from another country or shares no word with the vendor's names, because that marks a namesake.
**How each name is spelled.** Many registers only match the spelling they are given. Each name is searched as written, without its legal form, without a web domain, with "&" and "and" swapped, and with its words joined. A register gets up to three of these spellings, taken across the vendor's names so the first name cannot use them all.
**When a record binds.** A record binds when it carries one of the vendor's legal names with its legal form, however the register spaces it. Otherwise the name with its legal form set aside must match a distinctive name (more than one word), and every record so named must carry one legal form: "Clear Capital LLC" next to "Clear Capital Inc." binds neither. A trade name or d/b/a that the register lists beside the holder binds on the same rules. A one word brand never binds on its own.
**Enforcement and exclusion lists are stricter.** A record on an enforcement or exclusion list binds only on the exact name, legal form included. A namesake on an exclusion list ("Example Group FZCO") is never treated as the vendor ("Example Group Inc.").
Some national registers are also searched under the parent company's name. Those records are labeled **Parent company**.
## Reading the Licenses tab
The tab reads top to bottom: a verdict, the adverse records, the records found, then every register planned for the vendor.
The headline is one of: **No license register applies**, **License held on a register Coverbase does not read**, **No license record found**, a count of enforcement actions or exclusions on record, a count of licenses not active, a count of licenses with no published standing, or a count of active licenses across a number of jurisdictions. Enforcement actions and lapsed licenses are shown as critical. A callout under it says what to ask the vendor.
**No license record found** is not a clean result. A vendor offering a licensed service usually holds a license, so confirm the legal entity or ask the vendor for its license numbers.
Appears only when a regulator's enforcement action or an exclusion list names the vendor exactly. Read each action and ask the vendor how it was resolved.
One section per register, with every record it holds for the vendor: **Holder**, **Jurisdiction**, **License** (number and license type), **Status**, **Expires** and **Record**, which opens the register's own page. **Active** and **Not active** come from the register's status, or from the expiry date when the register gives no status. **Status not stated** means the register published neither. A record held by the parent company says so under the holder.
Every register planned for the vendor's lines of business, with **Line of Business**, **Jurisdiction**, **Register**, **Outcome** and a **Look up** link. Entity and enforcement registers are listed under **Entity, enforcement and national registers**. A summary line gives the number of registers, then how many were read, how many to check by hand, how many did not answer, and how many need no license or have no lookup.
**Registers Checked** lists the other registers searched by name, such as NASBA CPAverify, the FCA Register or state license data. **Not Checked** lists each register that did not answer and each one you need to check by hand. When more than four registers for one line need checking by hand, they are summarized as one line that names the jurisdictions, and each is linked on the **State and National Registers** list.
### Outcomes
| Outcome | What it means | What to do |
| - | - | - |
| A record count, or **No record matched** | The register was searched. The count is the records that matched the vendor; a search that matched nothing is shown in gray, not green. | Read the records. No match on a register that applies is a question for the vendor. |
| **Did not answer** | The register failed or ran out of time on this run. | Refresh later, or use **Look up**. Records it returned on an earlier run are kept, so an outage never reads as a license having gone. |
| **Check by hand** | The register is not searched automatically. The note says why. | Use **Look up** and search the vendor's legal name yourself. |
| **Not required there** | That state or country does not require what the register column names, such as a law firm registration. A lawyer's own bar admission is a separate check, listed under **Not Checked**. | Nothing. |
| **No public lookup** | The jurisdiction licenses the line but publishes no way to look it up. More than three such rows for one register are shown as one row with the number of jurisdictions. | Ask the vendor for a copy of the license. |
## Zero Touch license controls
The **Zero Touch License and Accreditation Validation** template asks the four license and accreditation controls, plus company identity, registration and ownership, disciplinary history and regulatory actions. A run that includes the **Licenses** section grades these controls from the vendor's stored license records, the same ones the **Licenses** tab shows, rather than from a second lookup.
| Control | Asks |
| - | - |
| ZT-LIC-01 | Every entity-level license the service requires is active on the issuer's register |
| ZT-LIC-02 | Those licenses cover every jurisdiction the vendor serves |
| ZT-LIC-03 | Each license is held by the contracting entity or a named affiliate that delivers the service |
| ZT-LIC-04 | Voluntary accreditations the service relies on (peer review, PCAOB, SOC reports) are current |
* The requirement comes from what the vendor does, never from a word in its name. When the license research finds that nothing the vendor does needs a license, and no register lists one, ZT-LIC-01 and ZT-LIC-02 are compliant, each with its own finding and the research's reason, and ZT-LIC-03 is not applicable on every scale, left out of the score where the scale has no Not Applicable level. This holds even when the vendor's own website cannot be read.
* A required license shown inactive, expired, suspended or revoked, with no active record beside it, is not compliant.
* A jurisdiction whose only records are inactive is a gap on ZT-LIC-02. An inactive record next to an active one in the same jurisdiction is history.
* A register that was not read is listed as a gap for the vendor to fill with a copy, not reported as a missing license.
* The automated review labels enforcement actions and exclusions as adverse.
A run that leaves the **Licenses** section out skips the license controls.
## Limits
* **Public registers only.** Coverbase reads what regulators publish. A license on a roll with no public lookup, such as a state bar admission, needs a copy from the vendor.
* **Registers that are not read automatically.** Some registers sit behind a CAPTCHA or a login, or are not read automatically yet. They are listed with a **Look up** link rather than left out.
* **Register outages.** A register that does not answer on a run is marked **Did not answer**, and its earlier records are kept until it answers again.
* **Names that differ from the legal name.** A license held under a name Coverbase does not know, such as an affiliate's, is not matched. If the vendor's legal name is missing or wrong, correct the corporate registration match on the **Registrations** tab and refresh. See [Corporate Registrations](/products/corporate-registrations).
* **A description that is too thin.** If the vendor's description does not say what it does, no line of business is chosen and only the entity filing and company registry apply.
## Related
The validated corporate identity every other answer is computed against.
The legal entity whose names the license lookup searches.
Triage assessments that grade the license controls from these records.
The screen by screen walkthrough.
# Monitoring plans and scorecards
Source: https://docs.coverbase.com/products/monitoring-plans
A schedule of ongoing monitoring for every active engagement: which activities a vendor owes at its tier, who owns each, when each is next due, how signals re-time it, the IRQ refresh with its answer diff, owner attestation, performance scorecards, contract obligations, and the Monitoring workbench for working them in bulk.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Your Coverbase representative turns on the third-party lifecycle features, including monitoring plans, for your organization.
A monitoring plan is the schedule an engagement follows once it is live. Your TPRM Office sets a cadence matrix once, by tier and activity, and every engagement gets a plan from it: which activities it owes, who owns each one, and when each is next due. A service that is not part of any engagement gets its own plan.
## What it does
For each tier of your risk scale, an interval in months and an owner (Transaction Owner or TPRM Office) for each activity: IRQ refresh, performance scorecard, owner attestation, evidence request and contract review. An organization that never saved a matrix gets a default, highest risk tier first.
The due diligence reassessment on the plan mirrors your reassessment schedule rather than keeping a second date. Moving it on the plan moves the reassessment schedule, so the reassessment is created on the new date. Continuous monitoring is Radar, always on while Radar is on for the vendor.
A Radar alert at or above a severity you choose, or a reassessment trigger, pulls the activities you name forward. The move is the monitoring agent acting on its own, so it also needs the **Re-time monitoring from feed signals** [agent policy](/products/agent-ledger#agent-policies), off by default. The move is applied at once and recorded with the signal that caused it, and the TPRM Office can keep it or revert it within an undo window.
The Transaction Owner refreshes the inherent risk questionnaire from the last approved answers. The TPRM Office sees every answer that changed, each domain's score and level before and after, newly in-scope domains and any tier change, then confirms. A new domain or a higher tier raises a reassessment straight away.
One question on the plan's cadence: is this still in use? Every answer is logged with the user and time. **Start offboarding** files a real offboarding request and pauses the plan.
A rubric bound to a tier and service category, scored by the respondents you name, with SLA adherence from the vendor's SLAs. A weighted score below your threshold is flagged.
![Monitoring Plan tab for the Media mix modeling engagement, with a banner saying a security rating drop moved the evidence request to October 29, 2026 and Keep and Revert buttons, a timeline of seven activities, and IRQ Refresh and Owner Attestation cards]()
## When a plan exists
A plan is generated when an engagement goes active, or a service outside any engagement goes active or completes. An executed contract, an approved engagement IRQ or a manual request from the TPRM Office also generates one before that. A daily sweep fills in any live engagement or service that has no plan.
A plan is re-planned when the tier moves, an IRQ is approved or a refresh is confirmed. Activities the TPRM Office edited keep their interval, owner and due date. The rest follow the matrix.
## Pausing
An engagement or service in a canceled status, an expired engagement, or any status you list under **Pausing Statuses** (such as On hold) pauses its plan. Pausing turns the vendor's Radar monitoring off only when no other live engagement or active plan needs it, and resuming turns back on only what the pause turned off. While every plan for a vendor is paused, reassessments are neither created nor reminded. On resume, due dates move out by the time spent paused.
## Notices
Each activity's owner is told before it is due, by the number of days you set. Past the overdue window, the owner and the TPRM Office are escalated to. Each due date is announced once. The sweep that sends these runs every day at 13:30 UTC.
## Comparing questionnaire submissions
The IRQ refresh shows a side-by-side diff of the refreshed answers against the last approved IRQ: every answer changed, added, removed or left alone, each answer's score, and each domain's score before and after. The same comparison is on the vendor's **Questionnaires** tab: **Compare** any finished submission with the vendor's earlier submission of the same questionnaire.
## Contract obligations
When a contract is signed, each obligation in its [clause pack](/products/clause-pack) that the signed contract carries becomes an activity on the engagement's plan, on the cadence its clause rule names. It is an ordinary activity. Notices, escalations, completion and pausing apply to it unchanged, and the timeline shows the obligation's own text.
## The Monitoring workbench
**Monitoring** in the left navigation lists every scheduled activity and every plan across your engagements and services, filtered by activity, due window and owner, with what you can see following your vendor access. The TPRM Office can **Reschedule** selected activities to a date or by a number of days, and **Send scorecards** now instead of at their notice window. Small selections run at once. Larger ones run in the background with progress. Each activity that cannot move says why, such as a paused plan or a date inside a reassessment's collection time, and the rest still go through.
![Monitoring page on the Activities tab listing six activities for the Media mix modeling engagement, each with its owner, due date, cadence and last done date]()
## Where to go next
Set the cadence matrix and rubrics, read a plan, refresh an IRQ and score a scorecard.
The signals that re-time a plan.
What Start offboarding sets in motion.
The engagement page the plan lives on.
# Obligations Tracker
Source: https://docs.coverbase.com/products/obligations-tracker
Track the obligations your organization takes on when engaging third parties: CUECs, legal terms, SOW duties, and technical controls.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Obligations Tracker keeps a living record of what your organization is responsible for when it engages a third party. Complementary user-entity controls (CUECs), contractual and legal terms, statement-of-work duties, and technical controls are extracted, assigned, and monitored so commitments don't fall through the cracks between procurement, legal, and the control owners who have to satisfy them.
## What it does
Capture obligations from SOC 1 and SOC 2 Type 2 reports (CUECs) and from contract documents such as MSAs, SOWs and order forms (shared responsibilities) into structured, trackable records.
Assign each obligation to an owner with a due date and status, so responsibility for every commitment is explicit and auditable.
Track complementary user-entity controls surfaced in vendor SOC 1 and SOC 2 reports, match them to your internal controls, and confirm your side of each shared-responsibility control is satisfied.
Monitor due dates and satisfaction across vendors, ask a business unit to acknowledge an obligation, and, with the Risk module, raise an overdue or unacknowledged obligation as a risk signal.
## How to integrate
List, retrieve, and filter obligations and their status programmatically.
Pull obligation commitments (who acknowledged what, and by when) into your GRC platform, contract management system, or compliance dashboards.
Query obligations conversationally. "Which CUECs are unsatisfied for our tier-1 vendors?" or "What obligations are due this quarter?"
Subscribe to `Obligation.*` events and react when obligations are created, updated (including reassignment), or deleted.
## Common workflows
When a vendor's SOC 2 lists complementary user-entity controls, Obligations Tracker captures each one, assigns the responsible owner on your side, and tracks confirmation so shared-responsibility gaps are closed before they become audit findings.
Obligations extracted by [Contract Guardian](/products/contract-guardian) flow into the tracker, where SLAs, audit rights, and notification duties are assigned and monitored against the live engagement.
When an amendment or a new report arrives, extract obligations from it, compare them with the ones already on file for the vendor, and archive or reassign what changed so the obligation surface stays aligned with the current agreement.
Obligations are surfaced through the [Obligations API](/api-reference/obligations) and the [MCP server](/mcp/overview), and their commitments through the [Export API](/export-api-concepts). Obligations extracted by [Contract Guardian](/products/contract-guardian) feed directly into the tracker. How to work them is in [Obligations](/user-guides/obligations).
# Offboarding and continuity
Source: https://docs.coverbase.com/products/offboarding-and-continuity
The end of an engagement, and the steps either side of the contract: the executed contract handoff, continuity plans for critical engagements, and offboarding with an exit plan that closes only on approved evidence.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Ending a vendor relationship takes more than archiving a record. The data has to come back or be destroyed, access removed, integrations disconnected, and the contract terminated with the right notice. Coverbase builds that work from what the engagement had, assigns each step, and closes a step only when its evidence has been approved. The same module handles the steps around the contract: the handoff that files the executed agreement, and the continuity plan a critical engagement carries.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
![Exit tab for Media mix modeling with an exit plan of three steps (data, access and contract), an Offboarding Request card in progress, and a What Stops Automatically card that keeps the vendor active because another engagement uses it]()
## What it does
A reason, a business justification and an optional requested date, approved by the TPRM Office and, once its group is named, Supply Chain. Marking an engagement not in use opens one automatically.
Steps for the data the vendor held, the access it had, its integrations, its contracts and the continuity plan, each with an owner and an approver. **Rebuild from current data** adds new steps without losing work already done. Evidence and approvals can be given for many steps at once, and **Remind owners** chases everyone a step waits on.
A step closes only when its evidence is submitted and its approver approves it. Document steps need a file, sign-off steps a note, and the data step the vendor's signed destruction certificate.
The vendor signs a data destruction certificate in the supplier portal. The signatory, title, time and a digest of the certificate are recorded, and approval is refused if the signed certificate has changed since it was submitted.
In-flight due diligence and a pending contract handoff stop when offboarding starts. When the plan closes, the engagement, its services, the vendor, Radar and the monitoring record are set inactive or closed, but only where no other live engagement still needs them.
An engagement at the top of its risk scale gets a draft continuity plan and a task for its Transaction Owner: backup suppliers, an exit strategy, a recovery time objective, resiliency notes and transition steps. Its transition steps become exit plan steps if the engagement is offboarded.
## The exit plan's sources
| Source | What Coverbase reads | The step |
| - | - | - |
| **Data it held** | IRQ answers about data, data processing, business associate and data sharing agreements, and the contract's data privacy terms | The vendor returns or destroys the data, evidenced by the destruction certificate. With nothing on record, an owner signs off that no data is held. |
| **Access it had** | The vendor's applications linked to an Okta or Entra application, with their assignment counts | Remove the single sign-on applications and assignments, evidenced by an export showing none remain. |
| **Integrations** | Applications with stored credentials, and API integration agreements | Disconnect each one. |
| **Contract** | Every linked contract that is not terminated | Send the termination notice within its notice period, or remove this engagement from a contract other engagements still use. |
| **Continuity** | The engagement's continuity plan | One step per transition step, plus confirming the backup suppliers can take over. |
## On the engagement tracker
An offboarding request moves the engagement's tracker to its **Exit** stage, which reads **Exit under way** until the plan closes and **Exited** with the date afterwards. See [Engagement record](/products/engagement-record#the-exit-stage).
## The contract handoff
When an assessment completes, a handoff opens on each engagement it was due diligence for that has not started yet, and Supply Chain (or the TPRM Office) gets a task to file the executed contract. Recording **Proceed to contracting** on a Risk Summary opens one too, and the TPRM Office can start one by hand. A contract signed through e-signature completes the handoff by itself. A contract signed on paper is completed by uploading the executed copy. Either way, the engagement moves to its active status and the Transaction Owner and the TPRM Office are notified.
## Routing
Offboarding approvals and the executed contract task go to two user groups set under **Configuration → Communications → Lifecycle Routing and Reminders**: the TPRM Office and Supply Chain. A task for a group follows the group's own assignment rule. With no TPRM Office group, offboarding approval falls back to the vendor's first risk analyst, then the requester. The approvals a request needs are fixed when it is filed, so changing the routing later cannot strand a request half approved.
## What it does not do
* Uploading a paper-signed copy does not mark the contract as executed in its signature workflow. Only the e-signature engines set that state. The handoff, the engagement status and the notices are the same either way.
* Canceling an offboarding does not undo what already stopped. A canceled assessment stays canceled.
## Where to go next
File a request, work the exit plan, write a continuity plan and complete a handoff.
Owner attestation, the most common way an offboarding starts.
How your own data comes back from Coverbase at the end of your contract.
Read engagements and their status from another system.
# People intelligence
Source: https://docs.coverbase.com/products/people-intelligence
A cited dossier on the people who run a vendor: executives, board, reporting lines, and what adverse-media screening found against them.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Corporate Registrations tells you the company is real. People intelligence tells you who runs it.
It answers the questions diligence asks about a counterparty's leadership. Who is accountable. How deep the bench is. Whether anyone named is carrying a sanctions listing, an enforcement action, or a live investigation. It answers them from public sources, without contacting the vendor.
The page is the **People** tab under **Vendor Intelligence**, alongside **Security**, **Financial** and **Registrations**.
## Confirmed and unconfirmed are not the same thing
This distinction shapes the whole page, so it is worth understanding first.
People research is dominated by one failure mode: namesakes. Search the leadership of a mid-sized company and you will reliably surface a better-known executive with the same name at a different firm. Presenting that person as the vendor's CFO is worse than returning nothing, because it looks like a finding.
Every name therefore lands in one of two groups.
Tied to this vendor by a source that resolved through the vendor's own domain, or by a matched professional profile. These are the only names that are counted, charted, or scored.
Surfaced in research but not tied to this vendor with confidence. Shown so you can judge them, and excluded from every count on the page.
Do not quote an unconfirmed name as the vendor's staff. It is a research lead, not a finding. The section exists so you can see what was considered and set aside, which is more useful than dropping it silently.
## What the page shows
**Coverage.** Confirmed people, executives and board currently serving, how many of those are corroborated by a registry filing, and how many were screened for news. A person named as an officer in a public filing is a stronger claim than one scraped from a leadership page, so the two are counted separately.
**Adverse media and screening.** Negative news, sanctions matches and enforcement matters tied to the people above. Each finding carries a category, a severity, an outcome, and a link to the source.
**Reporting lines.** Where published reporting relationships could be established, they are drawn as a tree. This is partial by nature. It reflects what is public, not the vendor's internal org chart.
**People.** A card per person: title, role, tenure, prior roles, other board seats, and links to the profiles that back them. Former staff are labelled rather than dropped, because a recent executive departure is often the thing you wanted to know.
## How the research runs
Screening is not a single "bad news" search. For each person, four separate queries run against news sources, covering litigation, regulatory and enforcement action, financial crime, and abrupt departures. The overlap between those corpora is small: a regulator's action rarely appears in the same results as a bankruptcy filing.
The results are then read into structured findings, with one instruction that matters more than the rest: discard anything that cannot be tied to this person at this company. Returning nothing is the correct answer for a person with no adverse coverage.
Screening is bounded and works top down. Founders and executives are screened first, then the board, then other leadership. The page records how many people were screened, and each person's card says whether they were among them.
A person who was not screened has not been cleared. Their card says so. This matters most on a large leadership team, where the tail of the list is exactly where an unscreened name could hide.
## Severity and outcome are separate
A dismissed fraud claim and a fraud conviction sit in the same category and are nowhere near the same fact.
Every finding carries both a severity (how serious the matter is) and an outcome (where it got to: alleged, under investigation, settled, concluded, dismissed, or unclear).
A finding marked **Dismissed** deducts nothing from the score. Scoring a claim the subject was cleared of would let anyone impose a lasting cost on a vendor by filing something that fails.
Findings the subject publicly contests are marked as disputed and shown with that label, so you are never handed one side of a contested matter as settled fact.
## No findings and not screened are different
If screening could not run, because a source was unreachable or the vendor has not been researched yet, the page says **Not screened**. It does not show a zero.
A zero reads as a clean record. The two mean opposite things. Everywhere this data appears, on the page, in the Zero Touch score, through the API, or to an agent over MCP, an unscreened vendor is reported as unknown.
This also governs scoring. When screening has not run, the People component of a [Zero Touch Score](/user-guides/zero-touch-assessments) deducts nothing at all, and labels itself so nobody reads the number as a clean bill of health.
## Where the data comes from
| Source | What it contributes |
| - | - |
| Org chart data | Serving staff resolved through the vendor's own domain, with titles, reporting lines and profile links |
| Web research | Leadership named on the vendor's own site and in public profiles |
| Public registers | Officers and directors named in corporate filings |
| News search | Litigation, regulatory action, financial crime and departure coverage, per person |
| Sanctions lists | OFAC SDN and consolidated screening against the confirmed names |
A sanctions match is reported at high severity, always with the caveat that name similarity is not identity. Confirm against the listing itself before acting on one.
## Using it
Reach for the page before an assessment, to see whether there is an accountable leadership team at all. A vendor with nobody on record is not disqualified, but it is a different conversation.
Turn on the People component in Zero Touch scoring when you want leadership visibility and adverse media to feed triage directly. See [Zero Touch Assessments](/user-guides/zero-touch-assessments).
Agents reach the same dossier over MCP with `query_vendors(kind="leadership", vendor_id="cbvndr_...")`. That is distinct from `kind="people"`, which returns your own team's owners and watchers on the vendor.
## Limits worth knowing
Coverage reflects what a company publishes. A private company that names nobody publicly will show little here, and that is a fact about its disclosure rather than its governance.
Reporting lines are reconstructed from published relationships and are usually incomplete.
People sharing a name are kept as separate records rather than merged. A nickname and a legal first name appear as two people. A visible duplicate is a better failure than a wrongly merged pair.
Politically exposed status is recorded as a fact calling for enhanced diligence. It is not a finding against the person.
None of this is a background check. It is open-source research, and it is where a conversation starts rather than where a judgement about an individual ends.
## Related
The screen-by-screen walkthrough.
The legal entity behind the vendor.
# Program Insights
Source: https://docs.coverbase.com/products/program-insights
Program Overview: the state of your third-party risk program on one page, with five KPIs, residual risk by business unit and risk domain, the pre-contract pipeline, six slicers, three levels, drill-downs into the matching lists, exports and distribution.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
**Program Overview** answers the questions a TPRM Office is asked every month: how many engagements are live, how much residual risk sits at the top of the scale and where, what is stuck in the pipeline before contract, and how long a request takes to reach a decision. Every figure opens the list behind it.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
![Program Overview showing 47 active engagements across 46 third parties, 22 of 56 scored at High or Critical residual, a heat grid of mean residual scores by business unit and risk domain, and the pre-contract pipeline by stage]()
## What it shows
**Active Engagements** (including those with an exit under way) across how many third parties; third parties or engagements at your elevated residual risk levels (such as High or Critical), with the change this quarter; **Reviews Past SLA** out of those in flight; **Issues Past Due**, with how many block a contract; and the median **Request to Decision** time over the last 90 days.
A heat grid of the mean residual score for each business unit and risk domain, coloured by your risk levels, with how many were scored and how many sit at the elevated levels.
Requests and engagements by stage, from **Request** through **Triage**, **Inherent risk**, **Due diligence** and **Decision** to **Contract**, until they reach a signed contract. Active, exiting and exited engagements are past the pipeline.
View the program at the **Enterprise**, **Engagement** or **Third party** level, and slice it by tier, business unit, contract type, control status, geography and risk domain. The view is held in the link, so sharing the link shares the view.
Each KPI, heat grid cell and pipeline stage opens the matching vendor, engagement or finding list, filtered to what it counts.
Export the view to Excel or CSV, generate the board pack, and see on the **Distribution** card where your program's data goes: warehouse destinations, the board pack schedule and scheduled dashboard emails.
## The three levels
| Level | Each row is |
| - | - |
| **Enterprise** | A third party at its worst: per domain, the higher of its own score and any of its engagements' scores. |
| **Engagement** | A live engagement, scored on its own. |
| **Third party** | A third party, scored by its rolled-up risk profile. |
## When a list shows more than the figure
When every slicer has a field on the list a figure opens, the list is filtered the same way. Otherwise the drill names the rows by ID, up to 100; past that, the list shows a superset of what the figure counted, and the page says so before you open it.
## Drill into a business unit or an engagement
From the whole program you can drill into one business unit, which narrows every figure to it and lists its third parties or engagements as the grid's rows, and then into one engagement. At the **Third party** level, a row opens the vendor page. The drill is held in the link with the level and slicers.
## Exiting and exited engagements
An engagement with an exit under way still counts as active, because its contract runs until the exit completes. Once the exit completes, the engagement leaves every figure, the same as an engagement the Transaction Owner decided not to proceed with. A drilled engagement that is active, exiting or exited says so under the pipeline bars.
## Where to go next
Read the page, slice it, drill in and export.
The tracker the pipeline stages come from.
The destinations on the Distribution card.
Build your own charts on the same data.
# RFP Platform
Source: https://docs.coverbase.com/products/rfp-platform
A complete RFP platform purpose-built for regulated industries, with risk, compliance, security, and legal evaluation embedded into vendor selection.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
RFP Platform brings vendor selection into the same risk-aware program as the rest of Coverbase. Built for regulated industries, it embeds risk, compliance, security, and legal evaluation directly into the request-for-proposal process, so the diligence that normally happens *after* a vendor is chosen instead shapes the decision while it's still being made.
## What it does
Describe what you need in a sentence. The wizard asks the clarifying questions, drafts the RFP, proposes a timeline, researches vendors, writes the weighted rubric, and generates the questionnaire. All of it is editable before anything is created.
Compare the field before contacting anyone. Coverbase researches how each shortlisted vendor would most plausibly answer, from public information, so ten candidates become three without spending anyone's goodwill.
Every AI score cites the verbatim span of the response it rests on, sits beside the reviewer's own score rather than replacing it, and fails a must-have on ambiguity rather than passing it.
Compare bidders across weighted criteria, with year-one and three-year cost side by side and a badge for how firm each number is: a published price, a quote, an indicative range, or withheld.
After the award, a record of why: the reasoning, each runner-up and the specific reason it lost, the risks knowingly accepted, and the conditions the winner must meet before signature.
Carry the winning bidder's responses and evidence straight into intake and assessment, with no re-keying of what was already collected.
## How to integrate
Hand a selected vendor directly to intake so the engagement enters the TPRM program at the correct depth.
Reuse RFP responses and uploaded evidence as the starting point for a scoped risk assessment.
Query RFPs conversationally. "Which bidders met our encryption requirements?" or "Summarize the security scores for this RFP."
## Common workflows
Evaluate bidders on capability and cost alongside security, privacy, legal, and compliance posture in one scorecard, so a cheaper bidder with unacceptable risk doesn't win by default.
When a winner is chosen, push their RFP responses and evidence into [Autonomous Intake](/products/autonomous-intake) and [Assessment Copilot](/products/assessment-copilot) so onboarding starts from what's already known.
Run sourcing events that satisfy regulatory expectations for documented, criteria-based vendor selection, with a defensible audit trail of how each decision was made.
## Getting started
The full walkthrough: the eight wizard steps, the seven sections of an RFP, running it without outreach, scoring against the rubric, and recording the decision.
RFP Platform is configured in the dashboard. RFPs can also be drafted, queried and compared through the [MCP server](/mcp/overview), and an awarded vendor is onboarded into the same vendor record that [Autonomous Intake](/products/autonomous-intake) and [Assessment Copilot](/products/assessment-copilot) work from.
# Risk methodology
Source: https://docs.coverbase.com/products/risk-methodology
One inherent risk model for intake, every Risk Group and every report: how domain scores roll up, who reviews each domain, when overdue work escalates, which questionnaire version is live, and how manual overrides are justified and expire.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The **Risk Methodology** page under **Configuration** holds the rules your inherent risk scores follow. Intake, every Risk Group's review and every report read the same settings, so a change made here applies everywhere at once.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
![Risk Methodology page with five tabs and the Risk Domains table listing eight domains, each not weighted, with the Risk Group reviewer for each]()
## What it covers
The domains an inherent risk questionnaire (IRQ) scores, the weight each carries, and the Risk Group that reviews it. With no weight on any domain, the questionnaire keeps its flat score.
How domain scores become one overall rating: a weighted average (the default), the highest domain, or a weighted average that never sits more than one tier below the worst domain.
Who reviews intake and each domain, by requesting group, business unit, tier and domain. The most specific matching rule wins.
When a work item is overdue by a set number of days, it is copied to or reassigned to a user, a group or a group's lead. Each rule escalates an item once.
Draft, publish and retire versions of an IRQ. Published and retired versions are read-only, every change is recorded in a changelog, and a content review cadence reminds the owner.
Every manual change to an inherent or residual score needs a written rationale. An override can expire after 30, 90, 180 or 365 days, with a countdown beside the score, after which the calculated score returns.
## How the score is built
1. **Domain scores.** Each scored answer contributes to the score of the domain its section belongs to.
2. **Weighting.** When at least one active domain carries a weight, the overall score is the weighted average of the domains that scored. Weights do not have to add up to 100, and a domain the questionnaire did not cover is left out rather than counted as zero. Answers in a section with no domain, or a domain with no weight, are counted and shown on the review so nothing is dropped silently.
3. **Aggregation method.** The org's method then applies. **Highest domain wins** replaces the score with the worst domain's score. **Weighted average with a domain floor** keeps the weighted score but lifts it to at least the lowest score of the tier one below the worst domain's tier, so a Critical domain makes the overall rating at least High. A domain on the lowest tier imposes no floor.
4. **Answer floors.** Last, any answer option that carries a minimum score lifts the whole questionnaire to that minimum.
![Why This Rating card listing the three answers that moved the score most, above an Inherent Risk What-If table where each answer can be changed to preview the rating]()
The IRQ review shows **Why This Rating**: the answers that moved the score most, which domain rated it or which floor lifted it, and any answers flagged for review. The aggregation method applies to questionnaires scored after you change it; scores already recorded are not recalculated.
## Routing and escalation
When an IRQ is approved, every domain it scored gets a review task for its Risk Group. The reviewer matrix decides who: a rule can name a requesting group, a business unit, a tier and a domain, and any criterion left on **Any** matches everything. With no matching rule, the domain's own reviewers review it. Intake review is matched before a tier is known, so only rules without a tier or domain apply to it.
Escalation rules run once a day over pending work items. **Notify** gives the target their own copy of the item, which closes when the original's record resolves. **Reassign** moves the item to the target. Every escalation is recorded on the item.
## Versions
An IRQ is a family of versions. At most one is published, and new sends always use it. Publishing a draft retires the previous version for new sends, while questionnaires already out finish on the version they were sent with. Lookups that find a vendor's response, such as a portal ask, an assessment plan or a workflow condition, match on the whole family, so naming a retired version still finds a response sent on its successor.
While a version is published or retired, its questions, sections, options and conditions cannot change. The editor offers **Draft new version** instead. Its name, reviewers and applicability stay editable.
**Compare** puts two versions side by side: sections, questions, answer options, weights, risk domains and review flags, each marked added, removed or changed, with a summary of what moved. Versions can be retired in bulk: a retired draft is discarded, and a fully retired questionnaire stops being sent until a new version is published.
## What-if scoring
Two what-if views rerun the real scoring without saving anything:
* **Inherent Risk What-If**, on a submitted inherent risk questionnaire: change answers and see where each domain and the overall rating would land, through the same weights, roll-up and answer floors.
* **Residual Risk What-If**, on an assessment's summary: turn on the open issues to remediate and see how far each drops its domain's and the overall residual risk, scoring each remediated issue at its compliant level, the same rule a finding's residual credit uses. A significant deficiency floor stays in force.
## Overrides
Editing an inherent or residual score by hand opens the score editor with a required **Rationale** and an **Override Expires** choice (**Never**, or after 30, 90, 180 or 365 days). A request without a rationale is refused. When an override expires, a daily job restores the last calculated score for each risk type the override changed. If something has replaced the override in the meantime, the newer score stands. While an override is active, a countdown reads **Override ends in N days** beside the score, and the vendor's risk profile shows **Override expired** on a score that lapsed.
## Where to go next
Set weights, the aggregation method, reviewer rules, escalation and versions step by step.
The packaged inherent risk questionnaires you can start from.
The IRQ scoping rules that decide when a request needs a questionnaire.
How domain-scoped reviews and approvals work on an assessment.
# Security Intelligence
Source: https://docs.coverbase.com/products/security-intelligence
An outside-in security rating measured from the vendor's own infrastructure, with every point deducted traceable to a specific observed configuration.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Security Intelligence rates a vendor's external security posture without asking the vendor anything, without an agent, and without a questionnaire. Coverbase queries the vendor's own public infrastructure (its DNS records, its TLS certificate, the headers its web server returns) and scores what it finds.
The distinction that matters: this is **measured**, not reported. A rating built from feed subscriptions tells you what someone said about a vendor. This tells you what the vendor's systems are configured to do, today, and shows you the record it read.
This is an optional feature. Ask your Coverbase representative to turn it on for your organization.
## What it does
A domain that publishes SPF and DMARC but sets `~all` and `p=none` blocks nothing. A presence check scores it identically to a domain enforcing `-all` and `p=reject`. Coverbase parses the policy and scores what it would do to a forged message.
Each factor lists the specific findings behind its grade: what was observed, on which host or selector, and how many points it cost. Open the rationale on any factor to see the arithmetic.
A finding carries the date it was first seen. A weak DKIM key that has been open for eleven months is a different conversation than one that appeared last week.
When a probe cannot reach a conclusion, that factor is excluded from the rating rather than scored as a failure. A timeout is not evidence about the vendor.
Each finding names the step that resolves it, written for whoever operates the asset. Forwarding one hands the provider a specific change to make rather than a problem to research.
Attribution is worked out from domain names, so it is sometimes wrong in both directions. Dispute an asset that is not the vendor's and it leaves the scan and the rating. Add one the scan cannot discover and it is probed and scored like any other.
Every profile carries a ranked list of next steps, each resting on a named observation: an actively exploited CVE, a database port open to the internet, a DMARC record that does not enforce. Each one copies a question ready to send to the vendor. The list is the same on the page, in a report and through MCP.
A refresh records what it found that the previous one did not, and the reverse: findings that appeared or were resolved, factors that moved, assets that arrived or left. A returning reader learns what is new in two lines rather than by rereading the page.
## What gets measured
Four probes read the vendor's live infrastructure on each Vendor Intelligence refresh. All four are passive: they read published records and make ordinary client requests, the same way any browser or mail server would. Nothing is scanned, brute-forced, or authenticated against.
| Probe | What it reads |
| - | - |
| **Email authentication** | The SPF `all` qualifier and lookup count, DMARC `p`/`sp`/`pct` and whether reports are collected, DKIM key size across the selectors major senders publish, MTA-STS mode fetched from the well-known URL, TLS-RPT, and BIMI |
| **Web application headers** | Whether the origin upgrades to HTTPS at all, HSTS and its lifetime, Content-Security-Policy (including report-only-only and `unsafe-inline`), clickjacking cover, MIME-sniffing protection, Referrer and Permissions policies, version banners, and the security flags on every cookie set |
| **TLS certificate** | Chain trust, whether the certificate covers the hostname, days to expiry, and the protocol and cipher negotiated |
| **Lookalike domains** | Registered typo and homoglyph variants of the vendor's domain that resolve, with mail-capable ones surfaced first |
These sit alongside the feed-based factors Coverbase already scored (vulnerability exposure, network posture, IP and web reputation, and credential leaks), so the rating covers both what the vendor's infrastructure does and what public sources report about it.
## How the score works
The overall score runs 0-100 with a letter grade, computed as a weighted mean across eleven factors. Weights reflect how directly each factor bears on a compromise:
| Factor | Weight | What it covers |
| - | -: | - |
| Patching cadence | 18% | Known-exploited and high-EPSS vulnerabilities in the vendor's products |
| Network exposure | 14% | Exposed services and administrative interfaces |
| Email authentication | 12% | SPF, DMARC, DKIM, MTA-STS, measured as policy |
| TLS configuration | 10% | Certificate trust, coverage, expiry, negotiated protocol |
| Web application headers | 10% | HTTPS enforcement, HSTS, CSP, cookie flags |
| DNS health | 8% | Resolver and record hygiene |
| Leaked credentials | 8% | Credentials exposed in known breaches |
| IP reputation | 7% | Malicious activity attributed to the vendor's addresses |
| TLS assessment | 6% | The SSL Labs grade for the vendor's site, and any configuration warnings |
| Web reputation | 5% | Reputation verdicts from public sources |
| Domain squatting | 2% | Registered lookalikes that resolve |
Two deliberate constraints on that arithmetic:
If a probe times out, gets rate-limited, or the vendor's infrastructure doesn't answer, that factor drops out of the weighted mean. It is never scored as a failure. A vendor is not penalized for a query that failed on our side, and a clean-looking score is never manufactured from a request that didn't complete.
The same rule applies in the other direction. HTTPS enforcement is credited only when a plain-HTTP connection is refused. A request that merely timed out proves nothing, so it earns nothing.
Uncapped, this factor measures brand recognition rather than security. Every large brand has dozens of parked typo domains it never registered and cannot remove. Before the cap, GitHub scored 0/100 on it. The cap keeps a real signal (a mail-capable lookalike is worth knowing about) from turning into a penalty for being well known.
## Reading a finding
Every factor's rationale lists the individual findings behind its grade. Each one carries:
* **What was observed**: the actual value, such as `p=none`, `1024-bit`, or `TLSv1.0`
* **Where**: the host, DKIM selector, or cookie name it applies to
* **What it cost**: the points deducted from that factor
* **How long it has been open**: the date the finding was first seen, once it has survived a refresh
That last field is the one worth watching. A finding that persists across months has been seen by the vendor's own team too. It has stopped being an oversight and become a decision.
Opening a finding also shows the remediation step for its code, and whether the finding cost the rating points. Raise a tracked finding from it directly, or use **Generate findings** to raise them for every scored issue at once, which is the case a sweep across a wide estate creates.
Take a finding to the vendor as an observation, not an accusation: "your DMARC record is `p=none`, so mail forged from your domain still gets delivered. Is enforcement on the roadmap?" It is a verifiable fact about a public record, and it converts a security review into a specific, answerable question.
## Next steps and the change log
Two things sit between the rating and the evidence, and both are derived from the scan rather than written by a model.
**Next steps** is a fixed set of rules over the profile, ranked urgent, soon and routine. Urgent rules fire on evidence of active exploitation or an open door: a CVE in CISA's Known Exploited Vulnerabilities catalog, a CVE tied to ransomware campaigns, an administrative or database service reachable from the internet, a failing certificate. Soon rules fire on policy gaps: DMARC at `p=none`, SPF ending in `+all`, TLS 1.0 or 1.1, a certificate within three weeks of expiry, a lookalike domain that accepts mail, staff credentials in a breach within a year of the scan. Routine rules fire on what weakens the rating itself: findings open for six months or more, an estate nobody has reviewed, and a rating that rests on less than 60% of the model's weight.
The rules are evaluated when the page, a report or an MCP client reads the profile, not when the scan ran. A rule added or tightened applies to every vendor on the next read, and every vendor scanned before the rules existed gets a list without a rescan.
**Since last scan** is stored by each refresh against the profile it replaces, because the replaced profile is the only place a resolved finding can be found. It records the score and factor movement, findings that appeared or closed, CVEs that appeared or are no longer observed, and assets that arrived or left. A finding counts as resolved only if its factor was measured in both scans, and CVEs are compared only if both scans reached the vulnerability source, so a skipped credential never reads as a fix.
The same two blocks reach assessment reports as `{{intelligence::security next steps}}` and `{{intelligence::security change since last scan}}`, and the security posture section an agent reads carries them in full.
## Standing among your vendors
With at least five rated vendors, the rating shows where this vendor sits among them: the share of the other rated vendors the viewer can open that it scores at or above. Someone restricted to assigned vendors is ranked among those, never against vendors they cannot see. It is computed when the page opens, from the ratings as they stand, so a vendor archived this morning is out of the cohort this morning. Below five rated vendors it is not shown, because two vendors make one of them "top 50%".
## Compared with industry peers
Your portfolio is not the vendor's market. The **Industry Comparison** on the Security tab rates the vendor against three to seven companies that sell a competing product to the same kind of buyer, chosen for the product your organization buys from the vendor. A model picks them from a web search and the competitors already on the vendor's fact sheet, and Coverbase drops any pick that is not a company's own website, the vendor itself, or its parent.
Every peer is scanned with the same outside-in scan as your vendors, and the result is stored as shared research: an organization buying the same product from the same company sees the same peers and the same ratings. The page shows the vendor's factor scores against the industry average as a radar chart, then each company's rating with its band, and the PDF export carries both. Peers are chosen again every 90 days, and a peer's rating is refreshed once it is more than 30 days old. See [Compared with industry peers](/user-guides/security-intelligence#compared-with-industry-peers) for how to read it.
## The predictive index
Alongside the rating, Coverbase publishes a forward-looking index of exploitation likelihood. It is driven by membership in CISA's Known Exploited Vulnerabilities catalog, peak EPSS probability, known ransomware association, and how much attack surface is externally exposed.
The rating answers "how well is this vendor configured?" The predictive index answers "how likely is something to happen soon?" They can diverge, and the divergence is informative: a well-configured vendor running one product with an actively exploited CVE deserves attention that its letter grade alone won't prompt.
## What this does not tell you
A clean external profile is **not** evidence of good internal security. Everything here is visible from outside the perimeter. It says nothing about access control, key management, secure development, incident response, or how the vendor treats your data once it's inside their systems. Use it to prioritize and to interrogate, never as a substitute for an assessment.
Three more limits worth stating plainly:
* **DKIM absence is inconclusive.** DKIM has no discovery mechanism; a verifier learns the selector from a message it received. Coverbase probes the selectors major senders publish, so a domain signing with a private selector reads as unsigned. Absence is therefore scored as *unknown* with a small deduction, never as a failure.
* **The rating describes the domain we scanned.** A vendor with a well-configured marketing domain and a neglected application domain will rate on whichever one is on file. **Scan a different domain**, beside the verdict on the Security page, points the scan at another one for every organization that monitors the vendor.
* **Attribution is heuristic, and correcting it is manual.** Disputing an asset fixes one vendor's estate; it does not make the attribution better for the next vendor. Adding the assets the scan cannot discover is the same trade in the other direction, and although they go in as one list against one rescan, someone still has to know they exist.
## Where it appears
The **External Security Intelligence** card carries the score, grade, factor breakdown, and per-factor findings, refreshed on the regular Vendor Intelligence cadence. The **Security** tab opens the same data full width, with rating history, every factor expanded to its findings, the reviewable estate, and a section per evidence class.
Measured posture is supplied to control evaluations as authoritative evidence, ranked ahead of web results. A control asking about email authentication is answered from the vendor's actual DNS records rather than from a marketing page claiming compliance.
A new vendor request is scored against measured posture before the web is consulted.
Ask conversationally: "What's the security posture for Acme?" or "Which of my vendors have DMARC set to none?"
## Availability
Security Intelligence is an optional feature, enabled per organization. **Contact your Coverbase representative to have it turned on.**
Organizations without it keep the security rating exactly as it was before this feature shipped: the same seven factors at the same weights. Enabling it adds the four measured factors and re-weights accordingly, so expect ratings to move once it's on. That movement is the point: the new rating distinguishes vendors the old one scored alike.
See also [Vendor Intelligence](/products/vendor-intelligence) for corporate identity validation and the [Financial Health Score](/products/financial-health-score), both enabled alongside this feature.
# Source library
Source: https://docs.coverbase.com/products/source-library
Every data source Coverbase draws on (due-diligence blocks, continuous-monitoring feeds, and partner integrations), organized into Core, Optional, and Premium tiers.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Coverbase assembles a vendor's risk picture from three layers of intelligence: **point-in-time due-diligence blocks** queried during onboarding and periodic review, **continuous-monitoring feeds** (Supplier Radar) that surface emerging signals in real time, and **partner integrations** you can connect to deepen coverage. This page catalogs every source across all three layers.
The library spans **450+ sources**, grouped into three tiers by how you get access. Use the tabs below to filter by tier, or read the tier definitions first.
## What the tiers mean
| Tier | What it means | How you get it |
| - | - | - |
| **Core** | Live and included in the platform today, at no additional cost or setup. | Coverbase operates the connection for you: public and free-tier feeds, or Coverbase's own keys. Nothing to configure. |
| **Optional** | Coverbase has a built API connection, but the feed runs on **your** subscription. | You contract with the provider directly and supply the API keys; Coverbase plugs them in. |
| **Premium** | Available through a Coverbase paid add-on or **reseller / partner** tier. | Access is arranged through Coverbase's commercial relationship with the provider; no self-serve key required from you. |
Sources are a starting point. You can add your own feeds, pages, or APIs alongside the built-in ones, and every source's scope (and the [detectors](/products/detector-library) that read it) is configurable in the dashboard. See [Supplier Radar](/products/supplier-radar) for the continuous-monitoring product and [Radar API](/api-reference/radar) for programmatic access.
Live and included today. Every source below is operated by Coverbase using public, free-tier, or Coverbase-held credentials: there is nothing for you to buy or configure.
### Cybersecurity news & advisories
| Source | What it covers |
| - | - |
| BleepingComputer | Cybersecurity, technology, and ransomware news |
| CISA Cybersecurity Advisories | Official alerts and advisories from the U.S. Cybersecurity and Infrastructure Security Agency |
| Cybersecurity Dive | In-depth news and analysis on breaches, vulnerabilities, and threats |
| SecurityWeek | Cybersecurity news, insights, and expert analysis for security professionals |
| Dark Reading | Widely-read cybersecurity community covering news, vulnerabilities, and threats |
| Dark Web Informer | Dark-web and cybercrime aggregator tracking breaches, ransomware, and threat intelligence |
| Krebs on Security | Investigative reporting on cybercrime, data breaches, and online fraud |
| The Hacker in a Hoodie Index (SEC 8-K cyber disclosures) | Curated ledger of SEC 8-K material cyber-incident disclosures: breaches, ransomware, and unauthorized access by public companies, each linked to its source EDGAR filing |
| The Hacker in a Hoodie Index (media-reported incidents) | Curated ledger of media-reported cyber incidents beyond SEC filings, with the reporting outlet and an attribution grade |
| BSI (Germany) - Cyber security warnings | Warnings from Germany's Federal Office for Information Security on vulnerabilities and threats |
| BSI (Germany) - Press releases | Press releases from Germany's Federal Office for Information Security |
| CERT-EU - Security advisories | Security advisories from the cybersecurity service for EU institutions |
| CERT-EU - Threat intelligence | Threat intelligence reports from the cybersecurity service for EU institutions |
| CERT-FR | France's national CERT alerts and advisories on vulnerabilities and threats |
| CIS - Cybersecurity advisories | Center for Internet Security advisories on vulnerabilities in widely used software |
| Cyber Security News | News on cyber attacks, vulnerabilities, data breaches, and malware |
| CyberScoop | News on cybersecurity policy, government, and the threat landscape |
| DataBreaches.net | Independent site reporting on data breaches, leaks, and ransomware incidents |
| ENISA - Publications | EU Agency for Cybersecurity reports on the threat landscape, guidance, and good practices |
| GBHackers | Cybersecurity news on vulnerabilities, malware, and attacks |
| JPCERT/CC - Advisories | Japan's computer emergency response team's alerts and advisories |
| NCSC-NL - Security advisories | The Dutch National Cyber Security Centre's advisories on vulnerabilities in widely used software |
| NIST Cybersecurity Insights Blog | NIST's blog on cybersecurity standards, frameworks, and guidance |
| NSA - Press releases and statements | National Security Agency press releases and joint cybersecurity advisories |
| SANS Internet Storm Center | Daily handler diaries on emerging threats, scanning activity, and attacks |
| UK NCSC - Guidance | UK National Cyber Security Centre guidance for organizations on security practices |
| UK NCSC - News | News from the UK National Cyber Security Centre on threats, incidents, and advisories |
### Vulnerability, exploit & threat intelligence
| Source | What it covers |
| - | - |
| NIST National Vulnerability Database (with KEV) | NIST's CVE database enriched with CVSS scores and CPE mappings, filtered to CISA KEV-listed vulnerabilities |
| MITRE CVE Program | The foundational CVE dictionary; new CVE assignments and CNA disclosures ingested as early-warning signals |
| CISA Known Exploited Vulnerabilities (KEV) | CISA's Known Exploited Vulnerabilities catalog: CVEs with confirmed active exploitation |
| FIRST EPSS (Exploit Prediction Scoring System) | Daily EPSS exploitation-probability scores for newly published CVEs |
| GitHub Security Advisories | GitHub Advisory Database of reviewed security advisories for open-source packages and ecosystems |
| Exploit-DB | Public exploit database cataloging proof-of-concept exploit code for disclosed CVEs |
| The Hacker News | Vulnerabilities, exploits, malware, and breaches |
| The Record | Threat-intelligence journalism on ransomware, nation-state activity, and breaches |
| Outside-In Threat Intelligence | Per-vendor outside-in intelligence: discovers CVEs for a vendor's Bill of Materials and marketed products, fuses CISA KEV exploited-status and EPSS probability, and adds attack-surface signals |
| CISA Known Breach Disclosures | Breach notifications and significant cyber incidents reported to CISA under CIRCIA and related frameworks |
| AWS Security Bulletins | Amazon Web Services security bulletins on vulnerabilities and issues affecting AWS services and software |
| Chainalysis Blog | Blockchain analytics research on crypto crime, sanctions evasion, and illicit finance |
| Check Point Blog | Check Point Software's blog on threat research, attacks, and security trends |
| Check Point Research | Check Point's threat research on malware, vulnerabilities, and threat actors |
| Cisco Talos Intelligence Blog | Cisco Talos research on malware, threat actors, and vulnerabilities |
| Cloud Security Alliance - Research | Cloud Security Alliance research and guidance on cloud and AI security |
| Coveware - Ransomware blog | Ransomware incident-response insights, trends, and threat-actor reporting |
| CrowdStrike Adversary Universe | CrowdStrike's catalog of tracked threat actors, watched for new and updated adversary profiles |
| CrowdStrike Blog | CrowdStrike research on adversary activity, threat intelligence, and incident response |
| Debian Security Advisories | Debian's security advisories for vulnerabilities fixed in its packages |
| Dragos Blog | Dragos research on industrial control system and operational technology threats |
| Dragos Threat Intelligence | Dragos threat intelligence on adversary groups targeting industrial infrastructure |
| Duo Blog | Cisco Duo's blog on identity security, authentication, and access threats |
| Elastic Security Labs | Elastic's threat research on malware, intrusion sets, and detection |
| ESET WeLiveSecurity | ESET research on malware, threat actors, and security news |
| FortiGuard Outbreak Alerts | Fortinet alerts on actively exploited vulnerabilities and widespread attack campaigns |
| FortiGuard PSIRT Advisories | Fortinet's product security advisories for FortiGate, FortiOS, and its other products |
| GitHub Blog - Security | GitHub's security blog on vulnerability research and open-source supply chain security |
| GitHub Security Advisories - npm | GitHub's reviewed advisories for vulnerabilities in npm packages |
| Google Chrome Releases | Google's Chrome release notes, including security fixes and exploited-in-the-wild disclosures |
| Google Cloud Security Bulletins | Google Cloud security bulletins on vulnerabilities affecting its services |
| Google Cloud Threat Intelligence | Google Threat Intelligence Group and Mandiant research on threat actors and campaigns |
| Google Security Blog | Google's blog on security research, vulnerabilities, and protections across its products |
| JVN (Japan Vulnerability Notes) | Japan's vulnerability notes database, run by JPCERT/CC and IPA |
| Kaspersky Blog | Kaspersky's blog on threats, scams, and security research |
| Malwarebytes Labs | Malwarebytes research and news on malware, scams, and threats |
| Microsoft Security Blog | Microsoft threat intelligence and security research on threat actors, campaigns, and defenses |
| Microsoft Security Update Guide (MSRC) | Microsoft's monthly security updates and CVE details for its products |
| MITRE ATLAS | MITRE's knowledge base of adversary tactics and techniques against AI systems |
| MSRC Blog | Microsoft Security Response Center posts on vulnerabilities, incidents, and security updates |
| Okta Security Advisories | Okta's advisories for vulnerabilities in its products |
| Okta Security Blog | Okta's security research on identity threats and attack techniques |
| Oracle Security Alerts | Oracle's critical patch updates and security alerts for its products |
| Palo Alto Networks Security Advisories | Product security advisories for Palo Alto Networks firewalls, Prisma, and Cortex |
| Proofpoint Blog | Proofpoint research on email threats, phishing, and threat actors |
| Red Hat Security Blog | Red Hat's security blog on vulnerabilities, open-source supply chain, and product security |
| Securelist (Kaspersky) | Kaspersky's threat research on APT groups, malware, and vulnerabilities |
| SentinelLabs | SentinelOne's threat research on APT groups, malware, and cybercrime |
| Sophos Blog | Sophos threat research and security news on malware, ransomware, and attacks |
| Symantec Threat Intelligence | Symantec research on threat actors, campaigns, and malware |
| Tenable Blog | Tenable research and analysis of newly disclosed and exploited vulnerabilities |
| Trend Micro - Ransomware news | Trend Micro research and news on ransomware groups and attacks |
| Trend Micro Research | Trend Micro research on threats, vulnerabilities, and cybercrime |
| Ubuntu Security Notices | Canonical's notices for vulnerabilities fixed in Ubuntu packages |
| Unit 42 (Palo Alto Networks) | Palo Alto Networks' threat research on threat actors, malware, and vulnerabilities |
| Volexity Blog | Volexity research on nation-state intrusions and zero-day exploitation |
### Attack surface & exposure (outside-in)
| Source | What it covers |
| - | - |
| Certificate Transparency (crt.sh) | Subdomain and certificate discovery from public CT logs |
| Qualys SSL Labs | TLS/SSL configuration grading for a vendor's public endpoints |
| DNS & MX records (Cloudflare) | Domain and mail-exchange records for DNS and email-security posture (SPF, DKIM, DMARC) |
| Norton Safe Web | Site reputation and safety signals |
| GreyNoise | Internet background-noise context: distinguishes targeted activity from benign scanners |
| VirusTotal | File, URL, domain, and IP reputation aggregated across dozens of engines |
### Service status
| Source | What it covers |
| - | - |
| GitHub Status (components) | Per-component operational status from GitHub's status page, watched as a snapshot so a degraded component shows up as a change |
| Alpaca Markets Status | Alpaca brokerage API status-page incident history |
| Amplitude Status | Amplitude's status-page incident history |
| Atlassian Status | Atlassian's status-page incidents across Jira, Confluence, and Bitbucket |
| AWS Health Dashboard | Amazon Web Services' public dashboard of service events across regions |
| Azure Status | Microsoft Azure's public status page of active service incidents |
| Barracuda Networks Status | Barracuda Networks' status-page incident history |
| Box Status | Box's status page, watched for incidents and degraded service |
| Chargebee Status | Chargebee's status-page incident history |
| Claude Status (components) | Anthropic's status page for Claude, watched per component for incidents and degraded service |
| Cloudera Status | Cloudera's status-page incident history |
| Cloudflare Status | Cloudflare's status-page incident history |
| Confluent Cloud Status | Confluent Cloud status-page incident history |
| Cybersource Status | Cybersource (Visa) payment platform status-page incident history |
| Datadog Status - Incident history | Datadog's status-page incident history |
| Docusign Status | Docusign's status page, watched for incidents and degraded service |
| Duo Security Status | Cisco Duo's status-page incident history |
| Elastic Cloud Status | Elastic Cloud's status-page incident history |
| ERCOT - News releases | News from the Electric Reliability Council of Texas, the grid operator for most of Texas |
| Fastly Status | Fastly's status page, watched for incidents and degraded service |
| Google Cloud Status | Google Cloud's service health incidents across products and regions |
| Google Workspace Status | Google Workspace service status dashboard |
| HashiCorp Status | HashiCorp's status-page incident history |
| Mixpanel Status | Mixpanel's status-page incident history |
| New Relic Status | New Relic's status-page incident history |
| OpenAI Status | OpenAI's status-page incidents for ChatGPT and the API |
| Palo Alto Networks Cloud Status | Palo Alto Networks cloud services status-page incident history |
| PayPal Status | PayPal's status-page incidents and maintenance notices |
| Plaid Status | Plaid's status-page incident history, including bank connection issues |
| SailPoint Status | SailPoint's status-page incident history |
| Salesforce Trust | Salesforce's trust site with service status and incidents across its instances |
| Segment Status | Twilio Segment's status-page incident history |
| Slack Status | Slack's status page, watched for incidents and degraded service |
| Splunk Cloud Status | Splunk Cloud Platform status-page incident history |
| Stripe Status | Stripe's status page, watched for incidents and degraded service |
| Sumo Logic Status | Sumo Logic's status-page incident history |
| Tenable Status | Tenable's status-page incident history |
| Twilio Status | Twilio's status page, watched for incidents and degraded service |
| Zoom Status | Zoom's status page, watched for incidents and degraded service |
### Sanctions, watchlists & PEP screening
| Source | What it covers |
| - | - |
| OFAC SDN List | U.S. Treasury Specially Designated Nationals and Blocked Persons list |
| OFAC Consolidated Sanctions List | SDN list plus additional OFAC programs (sectoral, country-specific) |
| UN Security Council Consolidated List | UN sanctions list of individuals, groups, and entities |
| EU Sanctions List | EU consolidated list of persons and entities under restrictive measures |
| HM Treasury UK Sanctions List | Post-Brexit UK sanctions regime maintained by HM Treasury |
| CBP - Forced labor | CBP withhold release orders and findings against goods made with forced labor |
| DHS - UFLPA Entity List | U.S. Department of Homeland Security list of entities tied to forced labor under the Uyghur Forced Labor Prevention Act |
| EBRD - Ineligible entities | European Bank for Reconstruction and Development list of firms and individuals barred from its projects |
| Federal Register - Bureau of Industry and Security | Bureau of Industry and Security notices, including Entity List additions and export-control rules |
| GOV.UK - UK sanctions guidance | UK government guidance on sanctions regimes and how to comply with them |
| OFAC - Recent actions | Office of Foreign Assets Control announcements of new designations, removals, and sanctions guidance |
| SAM.gov - Exclusions | U.S. federal System for Award Management exclusions of debarred and suspended contractors |
| SECO - Swiss sanctions and embargoes | Switzerland's State Secretariat for Economic Affairs page on Swiss sanctions and embargo measures |
| U.S. Consolidated Screening List | The U.S. government's combined export-control and sanctions screening list from Commerce, State, and Treasury |
| U.S. Treasury - Press releases | U.S. Department of the Treasury press releases, including sanctions designations and financial policy |
| UK OFSI - Financial sanctions | UK Office of Financial Sanctions Implementation notices, guidance, and penalties |
| UK Sanctions List | The UK government's list of persons and entities designated under UK sanctions regimes |
### Regulatory & enforcement actions
| Source | What it covers |
| - | - |
| SEC Stop Orders | Orders halting share sales under a materially misleading or deficient registration statement |
| SEC Litigation Releases | Civil actions brought by the SEC in federal court |
| SEC Administrative Proceedings | Litigated administrative proceedings adjudicated by the SEC |
| SEC Reports of Investigations | Investigative reports cautioning market participants on their federal securities-law obligations |
| CFPB Enforcement Actions | CFPB actions against providers for unfair, deceptive, or abusive financial practices |
| FCC Enforcement Actions | FCC actions enforcing the Communications Act and commission rules |
| FDIC Enforcement Actions | FDIC actions against insured depository institutions and affiliated parties |
| FinCEN Enforcement Actions | FinCEN actions for AML/BSA violations |
| HIPAA Journal Breach News | Healthcare data breaches, OCR enforcement, and HIPAA-related incident reporting |
| Acas - Latest news | News from Britain's Advisory, Conciliation and Arbitration Service on workplace disputes and guidance |
| AFM (Netherlands) - News | News from the Dutch Authority for the Financial Markets on supervision and enforcement |
| AMF (France) - All news | News from France's financial markets authority on regulation and supervision |
| AMF (France) - Press releases and sanctions | Press releases and enforcement sanctions from France's financial markets authority |
| AMF (France) - Publications | Reports, guidance, and publications from France's financial markets authority |
| APRA - Media releases | Australian Prudential Regulation Authority media releases on bank and insurer supervision |
| ASIC - Media releases | Australian Securities and Investments Commission media releases on enforcement and regulation |
| Australian Federal Police - Media releases | Australian Federal Police announcements on investigations, arrests, and cybercrime |
| BaFin - Enforcement measures | Enforcement measures and sanctions imposed by Germany's Federal Financial Supervisory Authority |
| BaFin - Press releases | Press releases from Germany's Federal Financial Supervisory Authority |
| Bank of England - Prudential regulation publications | Prudential Regulation Authority rules, supervisory statements, and consultations for UK banks and insurers |
| BfDI (Germany) - Press releases | Press releases from Germany's Federal Commissioner for Data Protection and Freedom of Information |
| Bundeskartellamt - News | News from Germany's Federal Cartel Office on merger control and antitrust cases |
| Bureau of Indian Standards - News | News from India's national standards body on product standards and certification |
| California DFPI - Enforcement actions | California Department of Financial Protection and Innovation enforcement actions against financial firms |
| CFPB - Newsroom | Consumer Financial Protection Bureau news on enforcement, rules, and consumer finance |
| CFTC - Enforcement actions | Commodity Futures Trading Commission enforcement actions and settlements |
| CFTC - Enforcement press releases | Commodity Futures Trading Commission press releases on enforcement actions |
| CFTC - Press releases | Commodity Futures Trading Commission press releases on enforcement, rules, and market oversight |
| CNIL - News | News from France's data protection authority, including sanctions and privacy guidance |
| Competition Bureau Canada - News releases | News releases from Canada's competition regulator on mergers, deceptive marketing, and cartels |
| Competition Commission of India - Press releases | Press releases from India's competition regulator on merger approvals and antitrust orders |
| CSBS - Newsroom | Conference of State Bank Supervisors news on state banking and money-transmitter supervision |
| CSSF (Luxembourg) - Publications | Publications and sanctions from Luxembourg's financial sector supervisor |
| Directorate of Enforcement (India) - Press releases | Press releases from India's financial crime agency on money-laundering and foreign-exchange cases |
| DOJ Antitrust Division - Press releases | U.S. Department of Justice Antitrust Division announcements on merger challenges and cartel cases |
| ECB Banking Supervision - Press releases | Press releases from the ECB's supervisor of significant euro-area banks |
| EEOC - Newsroom | U.S. Equal Employment Opportunity Commission lawsuits, settlements, and discrimination enforcement |
| EIOPA - News | European Insurance and Occupational Pensions Authority news on insurance and pensions supervision |
| ESMA - News | European Securities and Markets Authority news on supervision, guidance, and sanctions |
| EU Competition Cases - Search | European Commission antitrust, merger, and state aid case register |
| EU Competition Policy - News | European Commission news on antitrust, merger, and state aid decisions |
| EU Digital Strategy - News | European Commission news on digital policy, including AI, data, and platform regulation |
| EU Trade - Responsible business conduct | European Commission page on responsible business conduct and supply chain due diligence in trade policy |
| EUR-Lex - Official Journal of the EU | The Official Journal of the European Union, publishing EU legislation and official acts |
| European Anti-Fraud Office (OLAF) - News | European Anti-Fraud Office news on investigations into fraud against the EU budget |
| European Banking Authority - News | European Banking Authority news on banking regulation, stress tests, and supervision |
| European Commission - Have your say | European Commission consultations and feedback calls on upcoming EU legislation |
| European Commission - News | European Commission press releases and announcements on EU policy, regulation, and enforcement |
| European Data Protection Board - News | European Data Protection Board news, opinions, and binding decisions under the GDPR |
| European Labour Authority - News | European Labour Authority news on cross-border labor enforcement and mobility |
| European Medicines Agency - News | EMA news on medicine approvals, safety reviews, and shortages in the EU |
| European Parliament - Press releases | European Parliament press releases on legislation, votes, and committee work |
| Europol - Newsroom | Europol announcements of cross-border operations against cybercrime, fraud, and organized crime |
| FBI - Press releases | Federal Bureau of Investigation announcements on investigations, arrests, and fraud and cyber cases |
| FCA - News | UK Financial Conduct Authority news, final notices, fines, and policy statements |
| FDIC - Press releases | Federal Deposit Insurance Corporation press releases on bank failures, enforcement, and policy |
| Federal Maritime Commission - News | U.S. Federal Maritime Commission news on ocean shipping enforcement and rules |
| Federal Register | The daily journal of the U.S. government, publishing proposed and final rules, notices, and executive orders |
| Federal Register - CFPB | Federal Register rules and notices from the Consumer Financial Protection Bureau |
| Federal Register - Department of Labor | Federal Register rules and notices from the U.S. Department of Labor |
| Federal Register - FDIC | Federal Register rules and notices from the Federal Deposit Insurance Corporation |
| Federal Register - Federal Reserve | Federal Register rules and notices from the Federal Reserve System |
| Federal Register - FTC | Federal Register rules and notices from the Federal Trade Commission |
| Federal Register - NLRB | Federal Register rules and notices from the National Labor Relations Board |
| Federal Register - OCC | Federal Register rules and notices from the Office of the Comptroller of the Currency |
| Federal Register - SEC | Federal Register rules and notices from the Securities and Exchange Commission |
| Federal Register - State Department | Federal Register notices from the U.S. Department of State, including sanctions and export-control actions |
| Federal Register - Treasury | Federal Register rules and notices from the U.S. Department of the Treasury, including OFAC |
| Federal Reserve - Banking and consumer regulatory policy | Federal Reserve Board announcements on banking and consumer regulation |
| Federal Reserve - Enforcement actions | Federal Reserve Board enforcement actions against banks and their affiliated parties |
| Federal Reserve OIG - Press releases | Federal Reserve and CFPB Inspector General announcements on audits and investigations |
| Financial Reporting Council (UK) - News | UK audit and accounting regulator's news on enforcement, sanctions, and audit quality |
| FinCEN - Press releases | Financial Crimes Enforcement Network press releases on AML rules, advisories, and actions |
| FINRA - Disciplinary actions | Financial Industry Regulatory Authority disciplinary actions against broker-dealers and registered representatives |
| FINRA - Regulatory notices and news | Financial Industry Regulatory Authority regulatory notices, guidance, and news |
| FTC - Privacy and security business guidance | Federal Trade Commission guidance for businesses on privacy and data security obligations |
| Garante Privacy (Italy) - News | News from Italy's data protection authority, including sanctions and decisions |
| GOV.UK - Drug and device alerts | UK Medicines and Healthcare products Regulatory Agency alerts and recalls for medicines and medical devices |
| GOV.UK - Modern slavery | UK government guidance, statements, and statistics on modern slavery |
| GOV.UK - News and communications | UK government announcements, press releases, and policy news from every department and agency |
| GOV.UK - Product safety alerts, reports and recalls | UK government product safety alerts, risk reports, and recall notices |
| Government of Canada - News | Government of Canada news releases and announcements across federal departments |
| GovInfo - New publications | U.S. Government Publishing Office feed of new official publications from Congress, federal agencies, and the courts |
| Health Canada - Recalls and safety alerts | Health Canada's open data of recalls and safety alerts for consumer products, food, drugs, and vehicles |
| ICO - Enforcement action | UK Information Commissioner's Office fines, reprimands, and enforcement notices |
| Irish Data Protection Commission - Decisions | Decisions and fines from Ireland's data protection regulator, lead EU authority for many large tech firms |
| Irish Data Protection Commission - Press releases | Press releases from Ireland's data protection regulator on inquiries and decisions |
| Japan Fair Trade Commission - Press releases | Press releases from Japan's competition regulator on antitrust and merger cases |
| Justice Laws Website (Canada) - Acts | Canada's consolidated federal acts, watched for amendments and new legislation |
| legislation.gov.uk - UK statutory instruments | Newly made UK statutory instruments, the secondary legislation that implements Acts of Parliament |
| MAS - Enforcement | Monetary Authority of Singapore enforcement overview and actions |
| MAS - News and publications | Monetary Authority of Singapore news on monetary policy, regulation, and supervision |
| NERC - Newsroom | North American Electric Reliability Corporation news on grid reliability, standards, and enforcement |
| NERC - Reliability standards | North American Electric Reliability Corporation's reliability standards, watched for changes |
| NHTSA - Vehicle safety recalls | U.S. National Highway Traffic Safety Administration vehicle and equipment recalls |
| NIST - News | NIST news on standards, measurement, cybersecurity, and AI |
| NLRB - News | National Labor Relations Board news on unfair labor practice cases and decisions |
| OAIC - Notifiable data breaches | Australia's privacy regulator's notifiable data breach reports and statistics |
| OCC - Enforcement actions | Office of the Comptroller of the Currency enforcement actions against national banks and affiliated parties |
| OCC - News releases | Office of the Comptroller of the Currency news on national bank supervision, enforcement, and policy |
| Office of the Privacy Commissioner of Canada - News | News from Canada's federal privacy regulator on investigations and guidance |
| Office of the Privacy Commissioner of Canada - PIPEDA findings | Findings from Canada's federal privacy regulator under PIPEDA, including breach investigations |
| openFDA - Drug enforcement reports | U.S. Food and Drug Administration drug recall enforcement reports, via the openFDA API |
| openFDA - Food enforcement reports | U.S. Food and Drug Administration food recall enforcement reports, via the openFDA API |
| OSFI - News | Canada's Office of the Superintendent of Financial Institutions news on supervision and guidelines |
| OSHA - News releases | U.S. Occupational Safety and Health Administration citations, penalties, and workplace safety news |
| PDPC Singapore - Commission decisions | Enforcement decisions from Singapore's Personal Data Protection Commission |
| PDPC Singapore - Press room | Press releases from Singapore's Personal Data Protection Commission |
| Reserve Bank of India - Notifications | Reserve Bank of India notifications and circulars to banks and financial institutions |
| SEBI - Updates | Orders, circulars, and enforcement updates from the Securities and Exchange Board of India |
| SEC - Press releases | U.S. Securities and Exchange Commission press releases on enforcement, rulemaking, and agency actions |
| SFC Hong Kong - Circulars | Circulars from Hong Kong's Securities and Futures Commission to licensed firms |
| SFC Hong Kong - Press releases | Press releases from Hong Kong's Securities and Futures Commission on enforcement and policy |
| Singapore Ministry of Manpower - Newsroom | Singapore Ministry of Manpower news on employment rules, enforcement, and workplace safety |
| U.S. Customs and Border Protection - Newsroom | CBP announcements on trade enforcement, seizures, and border policy |
| U.S. Department of Justice - Press releases | U.S. Department of Justice announcements of indictments, guilty pleas, settlements, and civil actions |
| U.S. Department of Labor - News releases | U.S. Department of Labor news on enforcement, wage-and-hour cases, and labor policy |
| U.S. Department of Labor ILAB - Reports | U.S. Department of Labor reports on child labor and forced labor in global supply chains |
| U.S. EPA - Enforcement | U.S. Environmental Protection Agency enforcement cases, settlements, and compliance actions |
| U.S. Small Business Administration - Newsroom | SBA announcements on loans, disaster assistance, and small business programs |
| U.S. Trustee Program - Press releases | U.S. Department of Justice announcements on bankruptcy fraud and abuse enforcement |
| UK CMA - Cases | UK Competition and Markets Authority case updates on mergers, markets, and consumer enforcement |
| UK Insolvency Service | UK government updates on insolvency statistics, director disqualifications, and investigations |
| UK Office for Product Safety and Standards | UK government updates on product safety enforcement and standards |
| UK Trade Remedies Service - Cases | UK anti-dumping, countervailing, and safeguard investigations into imported goods |
### Breach notification registries & disclosures
Official registries where a breach becomes public because the law required someone to file it. These land days to weeks before press coverage and cover every filing, not only the companies a newsroom would write about. See the [breach notification monitoring guide](/user-guides/breach-notification-monitoring) for how to use them.
| Source | What it covers |
| - | - |
| California AG - Data Breach Notifications | Every breach notice filed with the California Attorney General, with the reporting organization, the breach dates, and the notice sent to residents |
| Delaware AG - Data Security Breach Database | Filings with the Delaware Attorney General, including Delaware residents affected |
| Washington AG - Data Breach Notifications | Filings with the Washington Attorney General, with Washingtonians affected and the categories of information compromised |
| Vermont AG - Security Breach Notices | Filings with the Vermont Attorney General, with the reporting organization's sector, residents affected, and data categories |
| Oregon DOJ - Data Breach Reports | Filings with the Oregon Department of Justice, with breach, discovery, and notification dates |
| Indiana AG - Security Breach Reports | Indiana's year-to-date registers, with dates and Indiana residents affected |
| Texas AG - Data Security Breach Reports | Filings with the Texas Attorney General since September 2021, with the information affected and Texans notified |
| Hawaii OCP - Security Breach Notices | Filings with Hawaii's Office of Consumer Protection, with how the breach happened, Hawaii residents impacted, and the notification letter |
| Rhode Island AG - Data Breach Notifications | Filings with the Rhode Island Attorney General, required of any breach touching more than 500 Rhode Islanders |
| Maryland AG - Security Breach Notices | Filings with the Maryland Attorney General, with Marylanders affected, what information was breached, and how |
| Iowa AG - Security Breach Notifications | Filings with the Iowa Attorney General, with the business, its industry, and the notice sent to Iowans |
| Massachusetts AG - Data Breach Notification Reports | Filings with the Massachusetts Attorney General, with residents affected and whether the data was encrypted |
| New Hampshire DOJ - Security Breach Notifications | Filings with the New Hampshire Department of Justice, published as the notice letters themselves |
| HHS OCR - HIPAA breaches affecting 500 or more | Every HIPAA breach of 500 or more records reported to the Office for Civil Rights, in all fifty states |
| FTC - enforcement and Health Breach Notification Rule actions | Federal Trade Commission actions, including Health Breach Notification Rule enforcement |
| SEC EDGAR - 8-K Item 1.05 cyber incident disclosures | Material cybersecurity incidents disclosed by public companies on the item created for them |
| SEC EDGAR - 10-K / 10-Q cybersecurity disclosures | Annual and quarterly reports discussing a material cybersecurity incident |
Not every state publishes what it receives. New York, and most states, take filings through a portal and publish nothing back, so there is nothing to monitor. Maine took its public database offline in June 2026 after fake filings were submitted against real companies. Wisconsin never collects the data at all: its law requires notice to affected individuals only, not to any state agency. Montana's breach page no longer exists. For every other state, coverage comes from the national sources above: HHS OCR spans all fifty states for healthcare, SEC EDGAR for public companies, and the FTC for federal enforcement.
### Natural hazards
Earthquakes, storms, floods, wildfires and severe weather warnings. These feeds never name a company: Coverbase matches each hazard to the vendors whose sites fall inside its area. See the [natural hazard monitoring guide](/user-guides/natural-hazard-monitoring) for how to use them.
| Source | What it covers |
| - | - |
| USGS Earthquakes (M4.5+) | Every earthquake of magnitude 4.5 or more worldwide, with depth, PAGER alert level and tsunami flag |
| GDACS Disaster Alerts (orange and red) | UN and European Commission alerts for earthquakes, tropical cyclones, floods, volcanoes, droughts and wildfires worldwide |
| NASA EONET natural events | Open wildfires, severe storms and their tracks, volcanic eruptions, floods and landslides worldwide |
| US National Weather Service - severe and extreme alerts | US tornado, severe thunderstorm and hail, flash flood, hurricane, winter storm, extreme heat and fire weather warnings |
| Meteoalarm - Sweden weather warnings | Orange and red warnings from the Swedish national weather service |
| Meteoalarm - the Netherlands weather warnings | Orange and red warnings from the Dutch national weather service |
| Meteoalarm - Germany weather warnings | Orange and red warnings from the German national weather service |
| GDACS - Global disaster alerts | UN and European Commission alerts for earthquakes, tropical cyclones, floods, volcanoes, and droughts worldwide |
| ReliefWeb - Updates | The UN humanitarian information service's reports on disasters, crises, and emergencies worldwide |
| USGS - Significant earthquakes | The U.S. Geological Survey's feed of significant earthquakes worldwide over the past week |
### Corporate & legal registration
| Source | What it covers |
| - | - |
| SEC EDGAR | Official registration and filing data for U.S. public companies (10-K, 10-Q, 8-K, proxies) |
| GLEIF | Global LEI Foundation: Legal Entity Identifier, legal name, entity status, jurisdiction, and addresses |
| OpenCorporates | Company registrations aggregated from official registries across 140+ jurisdictions |
| Companies House (UK) | UK government registry: officer appointments, filing history, and accounts |
| State-Level Business Registries (US) | Secretary of State filings across the 50 U.S. states for entity verification and good-standing status |
| ACRA - News and announcements | Singapore's Accounting and Corporate Regulatory Authority announcements on company registration and enforcement |
| London Stock Exchange - News | Regulatory news announcements from companies listed on the London Stock Exchange |
| Ministry of Corporate Affairs (India) - News and alerts | News and alerts from India's ministry that administers company registration and the Companies Act |
| NSE India - Corporate announcements | Corporate filings and announcements from companies listed on India's National Stock Exchange |
| SEC EDGAR - 8-K Item 1.03 bankruptcy filings | U.S. public-company Form 8-K filings reporting bankruptcy or receivership under Item 1.03 |
| The Gazette - Insolvency notices | The UK's official public record of insolvency notices, including winding-up petitions and administrations |
### Company & financial intelligence
| Source | What it covers |
| - | - |
| PitchBook | Private and public company intelligence: funding rounds, investors, valuations, and M\&A history |
| Crunchbase | Startup and growth-stage profiles: funding history, investor network, and acquisitions |
| Polygon.io | Public-markets data: ticker, market cap, list date, and stock financials |
| Perplexity | LLM-assisted resolution of private-company deal data, status, and public tickers |
| Tavily | Web-search enrichment powering a vendor's generated "scanned facts" |
| SafeBase | Vendor trust-center documents and published security posture |
| TheOrg | Org-chart and leadership enrichment |
| Atlassian Trust Center | Atlassian's trust center on security, privacy, and compliance, watched for changes |
| AWS Global Infrastructure | Amazon Web Services' page of regions and availability zones, watched for footprint changes |
| Azure Global Infrastructure | Microsoft Azure's page of regions and datacenter geographies, watched for footprint changes |
| Bankruptcy Observer | Tracker of new U.S. business bankruptcy filings |
| Cloudflare Trust Hub | Cloudflare's trust hub on security, privacy, and compliance, watched for changes |
| Crunchbase News | News on startup funding, venture capital, acquisitions, and layoffs |
| Docusign Trust Center | Docusign's trust center on security, privacy, and compliance, watched for changes |
| Google Cloud Locations | Google Cloud's page of regions and zones, watched for footprint changes |
| Google Cloud Partner Directory | Google Cloud's directory of partners, watched for changes in partner listings |
| Layoffs.fyi | Tracker of layoffs at technology companies and startups, watched for new entries |
| Morningstar | Investment research and news on companies, funds, and markets |
| Notion - Releases | Notion's product release notes, watched for new features and changes |
| Okta Trust Center | Okta's trust page on service status, security, and compliance, watched for changes |
| S\&P Global Market Intelligence - News and insights | S\&P Global Market Intelligence news and research on credit, sectors, and companies |
| Troubled Company Reporter | Daily newsletter on distressed companies, bankruptcy filings, and restructurings |
| Zoom Trust Center | Zoom's trust center on security, privacy, and compliance, watched for changes |
### Financial news & markets
| Source | What it covers |
| - | - |
| Bloomberg - Markets | Market data, equities, bonds, and finance news |
| Bloomberg - Economics | Economic news, central banks, and macro analysis |
| Bloomberg - Technology | Technology news, startups, and innovation |
| SeekingAlpha | Crowdsourced financial market news, analysis, and stock-market insight |
| AP News - Financial markets | Associated Press coverage of stocks, bonds, interest rates, and market-moving corporate news |
| AP News - Financial wellness | Associated Press coverage of personal finance, consumer credit, and household economics |
| Bank for International Settlements - News | News and research from the Bank for International Settlements, the central banks' bank |
| Bank of Canada - Press releases | Bank of Canada press releases on interest rates, monetary policy, and financial stability |
| Bank of England - News | Bank of England news on monetary policy, financial stability, and banking supervision |
| Bank of England - Publications | Bank of England reports, working papers, and financial stability publications |
| Bank of Japan - Announcements | Bank of Japan announcements on monetary policy, operations, and financial system reports |
| CME Group - Press releases | CME Group press releases on derivatives markets, trading volumes, and exchange operations |
| Deutsche Bundesbank - Speeches | Speeches by Deutsche Bundesbank officials on monetary policy and financial stability |
| Deutsche Bundesbank - Topics | Deutsche Bundesbank publications on monetary policy, banking supervision, and statistics |
| Economist Intelligence Unit - Country analysis | EIU country analysis and forecasts on political, economic, and business conditions |
| European Central Bank - Press releases | ECB press releases on monetary policy, financial stability, and euro-area markets |
| European Commission - Economic forecasts | The European Commission's economic forecasts for the EU and its member states |
| Federal Reserve - All press releases | All Federal Reserve Board press releases on monetary policy, supervision, and enforcement |
| Federal Reserve - Financial Stability Report | The Federal Reserve Board's semiannual assessment of vulnerabilities in the U.S. financial system |
| Federal Reserve - Monetary policy | Federal Reserve Board monetary policy statements and announcements |
| Federal Reserve - Speeches | Speeches by Federal Reserve Board governors on the economy, policy, and regulation |
| Financial Stability Board | Financial Stability Board reports and policy recommendations on global financial stability |
| ICE - Market data | Intercontinental Exchange market data announcements for its exchanges and indices |
| Japan Exchange Group - Listing | Japan Exchange Group listing notices, including new listings, delistings, and securities under supervision |
| Japan Exchange Group - News | Japan Exchange Group news on its markets, rules, and operations |
| Liberty Street Economics (New York Fed) | Federal Reserve Bank of New York economists' analysis of the economy and financial markets |
| MarketWatch - Bonds | MarketWatch coverage of bond markets, yields, and credit |
| MarketWatch - Top stories | MarketWatch top stories on markets, companies, and personal finance |
| New York Fed - Market updates | Federal Reserve Bank of New York statements on open market operations |
| NYSE - Continued listing | NYSE continued listing standards and lists of noncompliant issuers |
| OECD - Economy | OECD economic outlooks, forecasts, and analysis |
| OECD - Newsroom | OECD news releases on economic data, policy, and country reviews |
| ONS - Release calendar | UK Office for National Statistics releases on the economy, labour market, and prices |
| OTC Markets - Market news | OTC Markets Group news on over-the-counter securities markets |
| Reserve Bank of Australia - Media releases | Reserve Bank of Australia media releases on monetary policy and financial stability |
| Reserve Bank of Australia - Speeches | Speeches by Reserve Bank of Australia officials on the economy and monetary policy |
| SGX - Newsroom | Singapore Exchange news on its markets, listings, and operations |
| Swift - News | News from Swift on the global financial messaging network, standards, and payments infrastructure |
| TechCrunch - Venture | TechCrunch coverage of venture capital, funding rounds, and investors |
| Toronto Stock Exchange - Regulatory policies | Toronto Stock Exchange regulatory policies and procedures for listed issuers |
| World Bank - News | World Bank news on development finance, country economies, and projects |
### News & reputational
| Source | What it covers |
| - | - |
| CNN | Global breaking news |
| AP News | Fast, objective global newswire coverage |
| Reuters | International news across business, finance, politics, and technology |
| Bloomberg - Politics | Political news and policy coverage with financial and regulatory implications |
| Google News Alerts | Real-time, vendor-specific news alert subscriptions |
| Google News Feed | Broad news aggregation for ongoing reputational monitoring |
| ABC News - Business | ABC News business headlines on companies, markets, and the economy |
| Access Now | Digital rights organization reporting on internet shutdowns, surveillance, and privacy |
| AI Incident Database | Public database of real-world harms and near-harms involving AI systems |
| Amnesty International | Amnesty International news and research on human rights abuses worldwide |
| AP News - Tariffs | Associated Press coverage of tariffs, trade disputes, and their effect on companies and supply chains |
| AP News - U.S. news | Associated Press national news coverage across the United States |
| AP News - World news | Associated Press international coverage of conflicts, elections, disasters, and diplomacy |
| Automotive News | Automotive industry news on manufacturers, suppliers, recalls, and dealers |
| AWS Machine Learning Blog | Amazon Web Services' blog on machine learning and generative AI services |
| Biometric Update | Industry news on biometrics, digital identity, and the privacy rules that govern them |
| Business & Human Rights Resource Centre | Non-profit tracking the human rights impacts of companies, including allegations and company responses |
| CNA - Business | Channel NewsAsia business coverage with a focus on Asian companies and markets |
| Databricks Blog | Databricks' blog on data and AI platform features and company news |
| DatacenterDynamics | Trade publication covering data center construction, outages, power, and operators worldwide |
| EU Agency for Fundamental Rights - News | EU agency news and research on fundamental rights, including data protection and AI |
| Food Safety News | News coverage of foodborne illness outbreaks, recalls, and food safety regulation |
| Fox Business | Business news on markets, companies, and economic policy |
| FreightWaves | Freight and logistics news on trucking, shipping, carriers, and supply-chain disruption |
| Geopolitical Monitor | Independent publication of geopolitical analysis and country-risk commentary |
| GitHub Blog - AI | GitHub's blog posts on AI features, Copilot, and AI-assisted development |
| Google AI Blog | Google's announcements on AI research and products |
| Google Cloud Blog | Google Cloud's blog on products, AI, security, and customer news |
| Google DeepMind - Blog | Google DeepMind's research publications and AI news |
| Healthcare Dive | Trade publication covering health systems, insurers, health technology, and healthcare policy |
| HR Dive | Trade publication covering HR, workforce, employment law, and labor trends |
| Hugging Face Blog | Hugging Face's blog on open models, datasets, and machine learning tooling |
| Human Rights Watch | Human Rights Watch reporting on human rights abuses worldwide |
| International Labour Organization - News | International Labour Organization news on labor standards, forced labor, and working conditions |
| KnowTheChain | Benchmarks of how large companies address forced labor in their supply chains |
| Meta Newsroom | Meta's company announcements on products, policy, privacy, and AI |
| News On AIR (All India Radio) | India's public broadcaster's national news on government, politics, and business |
| NHRC India - Recommendations | Recommendations and case actions from India's National Human Rights Commission |
| NVIDIA Newsroom | NVIDIA's company announcements on products, partnerships, and AI |
| OCCRP | Organized Crime and Corruption Reporting Project investigations into corruption, money laundering, and organized crime |
| OpenAI - News | OpenAI announcements on models, products, safety, and company news |
| PBS NewsHour | Headlines on U.S. and world news, politics, and the economy |
| PR Newswire - All releases | Press release wire carrying corporate announcements on earnings, deals, leadership, and products |
| PR Newswire - Business and technology | Press release wire for business and technology announcements |
| Privacy International - News | Privacy advocacy group's reporting on surveillance, data exploitation, and privacy rights |
| Responsible Business Alliance - News | News from the industry coalition on supply chain labor, environment, and ethics standards |
| Sifted | European startup and venture news on funding, layoffs, and technology companies |
| Supply Chain Management Review | Trade publication on supply chain strategy, logistics, and disruption |
| TechCrunch - Layoffs | TechCrunch coverage of layoffs at technology companies |
| TechCrunch - Startups | TechCrunch coverage of startups, funding, and founders |
| The Economic Times | Indian business daily covering companies, markets, and the economy |
| The Seattle Times - Nation & world | The Seattle Times' national and international news coverage |
| UK Independent Anti-Slavery Commissioner | News and insights from the UK's independent commissioner on modern slavery and human trafficking |
| UK Parliament - Joint Committee on Human Rights | Inquiries and reports from the UK Parliament's Joint Committee on Human Rights |
| UN Global Compact - News | News from the UN corporate sustainability initiative on human rights, labor, environment, and anti-corruption |
| UN Press - Meetings coverage | UN meetings coverage and press releases, including Security Council deliberations and resolutions |
### Legal
| Source | What it covers |
| - | - |
| Law\.com - Corporate Legal | Legal news and analysis for corporate legal departments and in-house counsel |
| Anthropic - Legal | Anthropic's terms of service, usage policies, and privacy policy, watched for changes |
| AWS Service Terms | Amazon Web Services' service-specific terms, watched for changes |
| Box - Legal | Box's terms, privacy policy, and data processing agreements, watched for changes |
| Competition Appeal Tribunal (UK) - Cases | Cases and judgments from the UK tribunal for competition appeals and collective actions |
| Court of Justice of the EU - Case law | Judgments and opinions from the Court of Justice of the European Union |
| Dropbox - Privacy policy | Dropbox's privacy policy, watched for changes |
| European Patent Office - News | European Patent Office news on patent policy, decisions, and operations |
| Federal Court of Australia - Media releases | Media releases and judgment summaries from the Federal Court of Australia |
| IP India - News updates | Updates from India's patent, design, and trademark offices |
| Microsoft Licensing Documentation | Microsoft's product licensing terms and documentation, watched for changes |
| NCLT India - Orders | Orders from India's National Company Law Tribunal, including insolvency and corporate disputes |
| OpenAI - Policies | OpenAI's terms, usage policies, and privacy policy, watched for changes |
| Oracle - Legal | Oracle's legal notices, contracts, and policies, watched for changes |
| Ping Identity - Legal | Ping Identity's legal terms and policies, watched for changes |
| Salesforce - Legal | Salesforce's legal agreements and policies, watched for changes |
| Top Class Actions | News on class action lawsuits, settlements, and investigations against companies |
| U.S. Bankruptcy Court, District of Delaware - New filings | Docket feed from the U.S. Bankruptcy Court for the District of Delaware, a leading venue for corporate Chapter 11 cases |
| U.S. Copyright Office - NewsNet | U.S. Copyright Office news on rules, studies, and copyright policy |
| U.S. Court of Appeals for the Federal Circuit - Opinions and orders | Opinions and orders from the Federal Circuit, the appeals court for patent cases |
| U.S. Courts - News | News and announcements from the Administrative Office of the U.S. Courts on the federal judiciary |
| U.S. International Trade Commission - Section 337 | Section 337 investigations into unfair import practices, mostly patent and trademark infringement |
| UK Courts and Tribunals Judiciary - Judgments | Judgments published by courts and tribunals in England and Wales |
| UK Supreme Court - News | News and judgments from the Supreme Court of the United Kingdom |
| USPTO Patent Trial and Appeal Board | News and decisions from the U.S. Patent and Trademark Office's patent appeals board |
| USPTO Trademark Trial and Appeal Board | News and decisions from the U.S. Patent and Trademark Office's trademark appeals board |
| WIPO - Press room | World Intellectual Property Organization press releases on IP treaties, filings, and policy |
| WIPO Arbitration and Mediation Center | WIPO news on domain-name disputes and intellectual property arbitration and mediation |
Coverbase has a built API connection for each source below, but it runs on **your** subscription: you contract with the provider and supply the API keys, and Coverbase plugs them into your Vendor Intelligence and monitoring.
### Business identity & financial health
| Source | What it covers |
| - | - |
| Dun & Bradstreet - Identity Resolution | Matches vendors to a D-U-N-S number and establishes a canonical, deduplicated identity |
| Dun & Bradstreet - Company Information | Firmographics: industry classification, employee count, revenue, founding date, and geography |
| Dun & Bradstreet - Hierarchy & Connections | Parent, subsidiary, and branch linkage: concentration risk and beneficial-ownership chains |
| Dun & Bradstreet - Payment Insights | PAYDEX® score and tradeline-based payment-behavior indicators |
| Dun & Bradstreet - Financial Strength Insights | Composite stability view: D\&B Rating, Credit Recommendation, Delinquency Score, and Failure Score |
| Dun & Bradstreet - Higher-Tier Blocks | Deeper entitlements: Payment/Financial Strength Levels 2-3 and Global Failure Score, added to your D\&B connection |
### Attack surface & exposure (subscription)
| Source | What it covers |
| - | - |
| Shodan | Internet-exposed services, open ports, and banners across a vendor's attack surface |
| Censys | Internet-wide host and certificate scanning for exposure discovery |
| Have I Been Pwned | Vendor domain and credential exposure across known breach corpora |
Available through a Coverbase paid add-on or reseller / partner tier. Coverbase arranges access through its relationship with the provider: you don't supply your own key.
### Business identity, credit & verification
| Source | What it covers |
| - | - |
| Equifax - Business Verification (KYB) | Real-time Know Your Business verification with a fraud-potential index, OFAC screening, and adverse events |
| Equifax - Business Credit Reports & Risk Scores | Commercial credit intelligence, OneScore for Commercial, and business-failure/delinquency risk scores |
| Equifax - Commercial Financial Network (CFN) | Shared commercial data exchange combining payment performance with identity and firmographics |
| Equifax - Commercial Merchant Data | Near-real-time business activity from millions of merchant records to confirm a vendor is active and operating |
| Equifax - Identity Proofing / Kount 360 | Orchestrated identity and fraud platform for verifying vendor principals and beneficial owners |
### Sanctions, PEP & adverse media screening
| Source | What it covers |
| - | - |
| Equifax - Watchlist & Adverse Media Screening | 150+ sanctions and watchlists plus 30,000+ adverse-media sources via the Intelligent Match Engine |
| Equifax - AML Connect | Cloud-hosted AML screening across global watchlists, PEPs, and adverse media with ongoing monitoring |
| LexisNexis WorldCompliance | PEP, sanctions, adverse-media, and regulatory watchlist screening for BSA/AML programs |
| Refinitiv World-Check (LSEG) | Global KYC/AML due-diligence database covering PEPs, sanctions, state-owned enterprises, and adverse media |
### Financial health ratings
| Source | What it covers |
| - | - |
| Rapid Ratings | Financial Health Rating (FHR) scores and underlying performance metrics, distinct from credit ratings |
### Breach & leak intelligence
| Source | What it covers |
| - | - |
| IntelligenceX | Aggregated leaked datasets, breached databases, and dark-web intelligence for early exposure detection |
### Security ratings & outside-in monitoring
| Source | What it covers |
| - | - |
| BitSight | Continuous outside-in security ratings based on observed internet-facing behavior |
| SecurityScorecard | Continuous security-posture scoring across network, DNS, patching, and endpoint categories |
| Black Kite | Technical, financial, and compliance cyber-risk ratings for third parties |
| RiskRecon (Mastercard) | Automated third-party cyber-risk monitoring with asset discovery and remediation tracking |
| UpGuard | Outside-in monitoring for data-leak detection, typosquatting, and attack-surface management |
| Recorded Future | Real-time threat intelligence across the open, deep, and dark web |
| Mandiant | Threat intelligence and breach analytics from frontline incident response |
| Panorays | Automated third-party attack-surface assessment and security ratings |
| CyberGRX (ProcessUnity) | Exchange-based third-party cyber-risk assessments and analytics |
| Axio | Cyber-risk quantification and posture benchmarking |
| IONIX | Attack-surface discovery and exposure management across a vendor's connected assets |
### ESG & sustainability ratings
| Source | What it covers |
| - | - |
| EcoVadis | Sustainability ratings across environment, labor, ethics, and sustainable procurement |
| Sustainalytics | ESG risk ratings measuring exposure to material sustainability risks |
| ISS ESG | Corporate ESG ratings, controversy screening, and governance signals |
| CyberVadis | Third-party cybersecurity ratings built on a standardized assessment methodology |
### Legal (subscription)
| Source | What it covers |
| - | - |
| Law360 | Subscription legal news and analysis across practice areas and litigation |
## Related
The companion library of built-in detector templates that read these sources and flag matching events.
The full catalog of external systems Coverbase connects with, including GRC, procurement, and contract platforms.
The product overview: signal ingestion, enrichment, triage, and workflow orchestration.
Create radar events, and list, retrieve, and dismiss radar alerts programmatically.
# Supplier Radar
Source: https://docs.coverbase.com/products/supplier-radar
Continuous monitoring, triage, and response across your third-party ecosystem.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Supplier Radar watches threat intelligence feeds, public disclosures, sanctions and watchlists, breach databases, regulatory actions, and other external sources for events that touch your vendors. Every event your organization is exposed to becomes a **signal**, with a status, a severity, and a summary written for your portfolio, which you triage into a case, a finding, or a reassessment.
## What it does
Combine threat intel, breach databases, sanctions and watchlists, regulatory actions, and public disclosures into one event stream. See the [source library](/products/source-library) for every built-in source.
Normalize raw events and enrich them with the vendor's risk tier, services in scope, contract status, and owner so triage decisions have context.
Route signals into downstream actions: notify a vendor owner, open a finding, trigger a reassessment, or escalate to incident response.
## Key concepts
Four terms, in the order you meet them.
| Term | What it is | Where you see it |
| - | - | - |
| **Signal** | How Radar tracks an event's impact on your organization. When a new event arrives, Radar runs your detectors against it to judge the nature and severity of the impact and which of your vendors are exposed, then opens one signal with a title and summary written for your portfolio. A signal's severity is the highest severity any detector assigned to the underlying event. | The **Signals** tab, where you see newly arriving signals and the ones you have already triaged. |
| **Detector** | What decides whether an event matters to you. Each detector reads plain-language guidance, a severity threshold, category filters, and the sources it watches. When one fires, it records a verdict on each exposed vendor: severity, confidence, and reasoning. | The **Detectors** tab on a signal page shows which fired and why. Configured under **Configuration → Radar**. |
| **Case** | An investigation you open from a signal when it needs vendor outreach or a decision trail. | The **Cases** tab. |
| **Finding** | A confirmed problem on a vendor, with an owner and a due date. Create one from a signal once you know the vendor is affected, or one per exposed vendor in bulk. Creating a finding moves the signal to Triaged. | The **Findings** page, and on the vendor. Findings have their own product: see [Findings Manager](/products/findings-manager). |
### Signal statuses
Signals move through statuses as you work them. Dismiss one, acknowledge it, or open a case, a finding, or a reassessment from it, and the status follows.
| Status | Meaning |
| - | - |
| **Tracked** | A vendor you depend on is linked to the event, but no detector has alerted. The signal exists so you can see the exposure before anyone has decided it matters. |
| **Open** | No detector is alerting, but someone in your organization has handled the signal by hand: created it, edited it, or restored it after a dismissal. |
| **In alert** | At least one detector has fired on the event and stands by its verdict. This is the queue. |
| **Triaged** | You acknowledged the signal, or created a case or finding from it. |
| **Dismissed** | You dismissed the signal. Dismissing also teaches the detectors that fired to stay quiet on events like it. |
| **Closed** | A terminal status you set by hand from the signal page. Nothing moves a signal here on its own. |
The **In Alert** view shows signals that are in alert. **Triaged** shows what has already been acted on.
### Titles and summaries
Radar writes each signal's title and summary specifically for your organization, based on the event. The summary says what happened, when it occurred and when you were alerted, and which of your vendors are affected and how. It is regenerated when the detectors that fired change.
You can edit either by hand. **Regenerate summary** rewrites both from what the detectors currently report and replaces any hand edit. **Custom AI instructions** on the summary card apply to every generated summary in your organization: lead with regulatory exposure, name the contract owner, keep to two sentences.
### Exposure beyond the vendors named
An event names the vendors it is about. Radar also links the vendors that depend on them, through fourth-party relationships extracted from SOC 2 reports and subprocessor lists. A vendor whose uploaded SBOM lists an affected component is linked directly; see [Bills of materials](/user-guides/bill-of-materials#how-radar-uses-a-bill-of-materials). A breach at an identity provider becomes a Tracked signal for every vendor of yours that runs on it, before any detector has fired. The **Vendors** card on a signal page lists the vendors of yours linked to it.
## Risk propagation
A signal arriving changes nothing on a vendor. Radar moves residual risk only when you act on the signal, and only for detectors you have told to.
**What moves it.** Four actions: acknowledging the signal, creating a finding from it, starting a reassessment from it, and finalizing a case opened from it. Acknowledging is for the exposure that needs no case or finding but should still count against the vendor. Dismissing a signal leaves risk where it was.
**How far it moves.** Each detector carries a risk impact setting, off by default, with a minimum and maximum number of points out of 100 (1 to 10 unless you change them). When you act on one of its verdicts, Radar judges how severe the event is for that particular vendor and picks a value inside the range. The points land on the vendor's overall residual risk (when the detector's **Affect overall residual risk** is on) and on each risk domain the detector maps to. Inherent risk never moves. A verdict counts once, however many actions follow it.
**You see it before you are done.** After the action, **Review vendor risk profile updates** shows each affected vendor's residual risk, overall and per domain, as it now stands. Adjust any score or level and add a note, then **Save and continue**, or **Continue** to accept. Vendors on a case whose detectors do not update risk are called out and left unchanged. Organizations that do not track residual risk skip this step.
**Where you see it.** The vendor's risk profile shows the new residual score, and its risk history records the change and the detector behind it. Vendors reached through a fourth-party relationship are treated the same way: act on their part of the signal and their residual risk moves too.
## How to integrate
Create radar events, and list, retrieve, and dismiss radar alerts programmatically. Signals are not addressable through the API yet.
Turn a radar event or alert into a batch of vendor reassessments: curate, confirm, and run, without opening a case.
Subscribe to `RadarEvent.*`, `RadarDetectorResult.*`, and `Reassessment.*` events and react in real time.
Query radar alerts conversationally. "Any new radar alerts on tier-1 vendors in the past 24 hours?" or "Show me every vendor affected by the Northwind outage."
Pull radar events and findings into your SIEM, incident response platform, or executive dashboards.
## Common workflows
When a vendor is implicated in a breach disclosure, Radar surfaces every customer-side service that depends on that vendor, calculates blast radius, and routes incident notifications to the right owners automatically. No waiting for vendor self-disclosure.
Track regulatory actions, fines, and consent orders against vendors. Trigger reassessment workflows or contract review when a vendor's regulatory standing changes materially.
During industry-wide events (a major cloud outage, a widespread CVE, a sanctions enforcement action), Radar identifies every vendor in your portfolio with exposure and routes coordinated response across owners.
Detectors, sources, and default reviewers are configured in the dashboard under **Configuration → Radar**. Browse the built-in [source library](/products/source-library) and [detector library](/products/detector-library) to see what ships out of the box.
## Related
The analyst walkthrough: the In Alert view, reading a signal, and turning it into a case, finding, or reassessment.
The admin walkthrough: sources, detectors, and the tuning that keeps the queue quiet.
Every out-of-the-box detector template, by segment, with its default severity.
Events and alerts over REST, and how they map to what the dashboard shows.
# Vendor Intelligence
Source: https://docs.coverbase.com/products/vendor-intelligence
Validated corporate identity for every vendor: the legal entity, its standing, and its identifiers, from registries of record, with a citation on every fact.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Vendor Intelligence answers two questions about a company without asking the company anything: **is this corporation real and in good standing**, and **is it financially sound enough to depend on**. This page covers the first: the validated corporate identity every other answer is computed against. The second is the [Financial Health Score](/products/financial-health-score).
Both are assembled from registries of record and regulatory filings, and every figure on screen names the source it came from.
This is an optional feature. Ask your Coverbase representative to turn it on for your organization. It pairs with the [Financial Health Score](/products/financial-health-score) and [Security Intelligence](/products/security-intelligence), which are turned on the same way.
## What it does
Confirms the legal entity behind a vendor against GLEIF, OpenCorporates, and SEC EDGAR: official registered name, status, jurisdiction, incorporation date, addresses, and identifiers (LEI, DUNS, company number, SEC CIK).
A 0-100 score with five risk bands and a directional trend, computed from filed financial statements where they exist and from funding, headcount, and corporate-standing signals where they do not.
A short or ambiguous name binds only when two independent registers agree on the same legal entity. Agreement between registers outranks a few points of name similarity.
Each register is named with the identifier it matched on and a link to the record. A reviewer can verify a claim at its source instead of taking the platform's word for it.
## Corporate registration
Coverbase searches each register by company name, scores every candidate against the vendor's name, and binds a record only on a high-confidence match. A short or ambiguous name (for example, "Meta") binds only when two independent registers agree on the same legal entity.
When nothing matches confidently, the card shows **Needs review** rather than quietly picking the closest hit. That distinction matters: binding the wrong "Acme Holdings" is worse than returning nothing.
The **Licenses** tab searches the state, national and foreign registers that license the vendor's lines of business under the names this match settles; see [License and accreditation](/products/license-and-accreditation) for the method and the registers it reads.
| Source | What it establishes |
| - | - |
| **GLEIF** | Authoritative legal name, LEI, entity and registration status, jurisdiction, legal and headquarters addresses |
| **OpenCorporates** | Company number, jurisdiction, incorporation date, current status, link to the source registry |
| **SEC EDGAR** | US public-company validation: CIK, ticker, state of incorporation, SIC industry |
| **Dun & Bradstreet** | DUNS number, where your organization has its own D\&B entitlement |
## Financial Health Score
The other half of the answer lives on its own page. The **Coverbase Financial Health Score** is a 0-100 view of whether a vendor is financially sound enough to depend on, computed from filed statements where they exist and from funding, headcount, and corporate-standing signals where they do not, always labelled with which.
It depends on the corporate identity established above: the score is computed against the legal entity the registers bound, which is why a missed match shows up as a thinner score rather than a wrong one.
Confidence tiers, the five pillars and how their weights shift by tier, peer-relative ratio scoring, the caps and floors that override a weighted result, adverse events, and an honest account of coverage and limits.
## Where it appears
The **Corporate Registration** card sits in the identity column of a vendor's Vendor Intelligence section, refreshed on the regular cadence. The **Registrations** tab shows the legal entity, the evidence behind it, its corporate group, every register consulted, and **Correct with AI**.
Registry facts are supplied to control evaluations as authoritative evidence, ranked ahead of every web result. See [how evidence is sourced](#how-evidence-is-sourced).
Autofill and inherent-risk scoring consult the registers before searching the web, so a new vendor request is scored against its registered identity.
Ask conversationally: "What's the financial health score for Acme?" or "Is Acme a real registered company?"
## How evidence is sourced
A common assumption is that "web search" means handing a query to a search engine and reading the top results. That is not how Coverbase gathers evidence.
For any question about a company's identity, GLEIF, OpenCorporates, and SEC EDGAR are queried before any web crawl. Those facts enter as authoritative evidence in the prioritized bucket, ahead of every web result.
Where a registry and a web page disagree on a corporate fact, the model is instructed that the registry is correct. A register states a company's legal name and status as a matter of record; a search engine states whatever ranked well today.
Every candidate is classified for relevance to the specific control being evaluated **and** for publisher accountability: authoritative, reputable, or unreliable. Anything below the control set's minimum credibility is discarded, not merely ranked lower.
A control set configured to require authoritative sources will not cite a blog post. It will report that it found nothing, which is the correct answer.
## Availability
Vendor Intelligence is an optional feature, enabled per organization. **Contact your Coverbase representative to have it turned on.**
Corporate registration validation is populated for every organization on each Vendor Intelligence refresh. What requires enabling is the presentation of it (the Corporate Registration card leading the identity column, the registry-verification chip, and the shared citation strip) along with registry-first retrieval. Nothing about an existing Vendor Intelligence record changes until they are on.
Coverage is honest about its edges. OpenCorporates coverage varies by jurisdiction, SEC EDGAR only covers US registrants, and a DUNS number requires your own entitlement with that provider. In every case the card names which sources were consulted and which were unavailable, rather than presenting a thinner answer as a complete one.
# Warehouse data share
Source: https://docs.coverbase.com/products/warehouse-data-share
Push your third-party risk tables to your own Snowflake account, Amazon S3 bucket or BigQuery dataset on a schedule, so Power BI, Tableau or your data lake read them without going through the API.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Your Coverbase representative turns on the third-party lifecycle features, including data share, for your organization.
Data share writes the tables behind your third-party risk program into storage you own, on a schedule. Your BI team models against stable tables and views in their own warehouse instead of paging through an API, and nothing has to be exported by hand.
## What it does
Snowflake (key-pair authentication through the SQL API), BigQuery (a service account key), and Amazon S3 (a role in your account that Coverbase assumes, with no stored secret).
Each sync appends the rows that changed since the last successful one, stamped with when they were written. A failed sync is retried from the same point by the next.
In Snowflake and BigQuery, each table has a `_current` view that keeps the newest version of each row. Point your BI model at the views.
Eighteen tables, from third parties, engagements and per-domain scores to findings, risk acceptances, contracts, obligations, monitoring and Radar. Columns are added over time but never renamed or removed in place.
![Data Share page with an Add destination button, no destinations yet, and the Table Contract listing eighteen tables such as third_parties, engagements, services, assessments, findings and contracts with their sync type and column count]()
## Schedule
Each destination syncs **Hourly** or **Daily**, and on demand with **Sync now**. A **Sync now** that lands while a scheduled sync of the same destination is running is dropped rather than run twice.
## What lands where
* **Snowflake and BigQuery:** one table per contract table, created on the first sync. A column the contract adds later is added to the table. Beside each table, a `_current` view keeps the latest version of each row.
* **Amazon S3:** files in gzip CSV, gzip JSON Lines or snappy Parquet at `//synced_date=YYYY-MM-DD/-.`, with each table's contract at `/_contract/.json`. Deduplicate on `id`, keeping the latest `_cb_synced_at`, the same way the views do.
Timestamps are UTC. Archived records stay in the share with `is_archived` set. A hard delete is not sent, except that the `services` table is a full snapshot on every run, so a deleted service drops out of its current view.
## Credentials
A destination's credential is write-only. It is stored in a secrets manager the moment you submit it, and the page shows only a non-secret hint: the key's fingerprint for Snowflake, or the service account email for BigQuery. Archiving a destination deletes its credential. Amazon S3 stores no secret at all. Coverbase assumes your role with an external ID generated for that one destination. See [Integration credentials and signing](/security/integration-credentials#customer-s3-roles-and-external-ids).
## Where it shows
The **Distribution** card on [Program Overview](/user-guides/program-insights), under **Dashboards**, lists each destination with its status and last sync, beside the board pack and your scheduled dashboard emails.
## Where to go next
Add a destination, test it, read the run log and the table contract.
Key-pair setup and the grants the Snowflake user needs.
The role, its trust policy and the external ID.
The service account and its roles.
# Zero Touch Assessments
Source: https://docs.coverbase.com/products/zero-touch-assessments
A triage assessment assembled entirely from open-source research, with no vendor outreach.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Most vendor programs have more vendors than review capacity. The usual result is that the long tail goes unassessed, and nobody knows which of those vendors deserved attention.
A Zero Touch Assessment is a triage run for that tail. It evaluates a vendor against a fixed set of controls using open-source research, produces a single 0 to 100 score, and never contacts the vendor. Run it across a whole portfolio and rank what comes back.
## What it is, mechanically
It is an ordinary assessment on the ordinary pipeline, with the same controls, issues and evidence as any other run. Three things differ.
The control scope is fixed per organization. Seven templates ship with the product: a comprehensive default, lighter and industry-specific variants, and one for open-source software. Your organization runs one at a time, so every run evaluates the same questions and the results stay comparable. Each run records which template it used.
There is no outreach. No document request, no questionnaire, no portal. The evidence is web research, public registers, the vendor's own infrastructure, and any documents already on file.
Nothing is assigned. A run needs no reviewer, no follow-up and no vendor reply, so a batch can be launched and left to finish.
## It answers "what is this vendor?" first
The common case is knowing a vendor is in use without knowing what it does. Every run opens with the company itself: what it sells, its industry, what it would typically be used for, its services and headquarters, all researched from public sources rather than asked.
Alongside it sits a **risk tier**: a triage read of how much exposure the vendor typically creates, from critical to minimal, with the reasoning behind it. The tier is its own scale, not your organization's risk levels, because those are calibrated against a completed questionnaire and this is judged from the outside. It leaves your vendor risk scores alone unless you explicitly turn that on.
Identity confidence and risk-tier confidence are reported separately. A run can be certain which company it profiled and still be unsure how exposed that company makes you.
## It gathers the reputational picture into one section
The evidence a reputational read needs arrives from three unrelated places: adverse
media on the vendor's leadership, open watchlist matches where an organization
screens, and the reputation controls the run evaluates itself. Every run pulls all
three into a **Reputation** section and files what they found under five
dimensions: media and customer sentiment, litigation exposure, regulatory and
enforcement, executive conduct and stability, and sanctions and association.
Each dimension reports its own standing, and the section reports the standing of the
worst of them. Findings are ordered material first, so the row that matters is at the
top. A matter the subject was cleared of is still listed, because it is part of the
record of what the run read, but it is not counted as material and it does not deduct.
### Not screened is never reported as clear
A dimension nothing searched reads **not screened**, never **clear**. The two look
similar on a page and mean opposite things, so the section names every unscreened
dimension rather than leaving a short findings list to imply a clean vendor. A
dimension goes unscreened when the template carries no control for it, the vendor has
no leadership dossier yet, or the organization does not screen the relevant watchlist
feed.
The section comes straight after the vendor identity and the risk tier reasoning, in
the app and in the PDF, and the spreadsheet gives it the second tab and repeats its
read on the summary sheet under the score.
## The score
The composite combines up to five independently sourced components.
| Component | What it measures |
| - | - |
| Control evaluation | The Zero Touch control sets, scored against open-source research |
| Financial health | The vendor's [Financial Health Score](/products/financial-health-score) |
| Security | The outside-in [security rating](/products/security-intelligence) |
| Corporate registration | Whether a standing legal entity was [matched in a public register](/products/corporate-registrations) |
| People intelligence | Leadership on record, less what [adverse-media screening](/products/people-intelligence) found |
Each is scored 0 to 100 on its own, then weighted into one number carried on your organization's own risk scale.
License controls (ZT-LIC) are graded from the vendor's stored license records, found by the lookup described in [License and accreditation](/products/license-and-accreditation).
### A missing component is excluded, never zeroed
This is the rule that governs everything else.
A vendor with no filed financials has not failed the financial component. It has no financial component. The weights renormalise across whatever did resolve, so the composite never manufactures a low score out of an absent input.
The consequence is that a vendor scored on one component is not comparable to a vendor scored on three. The result carries both the weight a component was configured with and the share it carried, so you can see which you are looking at.
The same principle governs the people component. When adverse-media screening did not run, nothing is deducted, because a screening that never happened cannot establish a clean record.
## What you can do with a result
Approve it, escalate it to a full assessment, revise it from analyst notes or vendor evidence, or correct what the run was built on.
That last one exists because open-source research binds the wrong website or a similarly named company often enough to need a first-class fix. You describe the correction in plain language, the run is re-scored against the corrected inputs, and your words plus the resulting field changes are written to an append-only audit trail.
The trail cannot be edited or deleted, by anyone. A Zero Touch score can be written onto a vendor's real risk score, so the record of who changed the inputs behind it has to be one nobody can rewrite.
## Where the score goes
By default it stays on the run. You can configure it to write onto the vendor's inherent or residual risk score, or onto each service the run covered.
Only the axis you choose is written, so a Zero Touch run can never overwrite an inherent score your team set deliberately from an intake questionnaire.
## What it is not
It is not assurance. A run has never spoken to the vendor, so it cannot confirm a control is operating. It can only tell you whether public evidence supports it.
Anything you need to show an auditor needs a full assessment. Zero Touch tells you which vendors those are.
## Related
The screen-by-screen walkthrough.
Launch, rank, re-score and read the audit trail.
# Authentication
Source: https://docs.coverbase.com/quickstart
All Coverbase API requests are authenticated with a bearer token over HTTPS.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
The Coverbase API uses bearer token authentication. Every request must include a credential in the `Authorization` header. For the full set of cross-cutting rules (IDs, timestamps, idempotency, error envelope) see [API conventions](/conventions).
API keys grant significant access to your TPRM data. Never share them in public repositories, client-side code, screenshots, or support tickets. Treat them like passwords.
## Request an API key
An admin in your organization creates API keys on the **API keys** page (**Configuration**, under **Developers and integrations**) or through the [API Keys API](/api-reference/api-keys). Each key looks like `ak_...`, is scoped to a single organization, and authenticates as a service account. All data it can read or write is implicitly scoped to that org. Ask your admin for one.
A logged-in user JWT (the dashboard session token) is also accepted, which is convenient for first-party scripts running as a user.
By default a key carries no elevated permissions and can only call ordinary `/v1/*` routes. An admin can also mint a key with **admin scopes**: `keys:manage` (manage `ak_*` keys), `audit:read` (read the system audit log), `banking:read` (read full supplier bank and tax identifiers), and `review:sensitive_changes` (write bank details without waiting for review). The admin-JWT path still works for the key and audit-log endpoints. See [API key scopes](/conventions#api-key-scopes) and the [API Keys reference](/api-reference/api-keys).
## Base URLs
| Environment | Base URL |
| - | - |
| Production | `https://api.coverbase.app` |
See [API conventions → Base URLs](/conventions#base-urls).
## Authorization header
Include your key as a bearer token in every request:
```text theme={null}
Authorization: Bearer ak_...
```
## Test your connection
Use the `/v1/utils/authtest` endpoint to verify three things at once: your key is valid, you can reach Coverbase's servers, and your firewall or proxy allows outbound HTTPS traffic.
```bash cURL theme={null}
curl -H "Authorization: Bearer ak_live_xxx" \
https://api.coverbase.app/v1/utils/authtest
```
```python Python theme={null}
import os
import requests
API_KEY = os.environ["COVERBASE_API_KEY"]
BASE_URL = "https://api.coverbase.app"
response = requests.get(
f"{BASE_URL}/v1/utils/authtest",
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=30,
)
response.raise_for_status()
print(response.json())
```
A successful request returns `200 OK`:
```json theme={null}
{ "msg": "Auth successful" }
```
## Common errors
Your credential is malformed, expired, or revoked (`Invalid or expired API key.` for an `ak_` key), or its role is not permitted on the endpoint (`Unauthorized role.`). Confirm the key is active and that the endpoint accepts API keys.
A request with no `Authorization` header, or with a scheme other than `Bearer`, returns `403` with `Not authenticated`. Otherwise your credential is valid but not authorized for what it tried to do: most often an `ak_*` key calling an admin endpoint without the required scope (`insufficient_scope`), or a non-admin caller trying to grant scopes when creating a key (`scope_grant_forbidden`). A configured [API IP allowlist](/conventions#api-ip-allowlist) can also return `403 ip_not_allowed`. See [API key scopes](/conventions#api-key-scopes).
The resource does not exist, or it belongs to a different organization than your API key. All data is org-scoped to the key.
Check your VPN, proxy, and firewall rules. Coverbase requires outbound HTTPS access to `api.coverbase.app`.
Unauthenticated requests are rejected. There is no public unauthenticated surface area on the API.
# Custom Word report templates
Source: https://docs.coverbase.com/reporting/assessment-report-templates
Build a .docx assessment report template: placeholder syntax, AI-written sections, repeating findings tables, signature anchors, and the rules that govern substitution.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
A report template is an ordinary Word document that contains **placeholders**. When you export an assessment against the template, Coverbase copies the document, replaces each placeholder with live data, and returns a finished `.docx` with your formatting intact.
For the complete list of what you can put between the braces, see the [placeholder reference](/reporting/template-placeholders).
## Uploading a template
An admin turns on the **Assessment report templates** toggle in **Configuration > Assessment Settings > Reports**. The upload panel appears directly below the toggle. Until this is on, the Word export option does not appear on assessments.
Write your report in Word exactly as you want it to look. Put placeholders wherever data should appear. For a working example, click **Download Example** in the upload dialog. **Variables Catalog** in the same dialog lists every placeholder your organization can use, with its exact spelling.
In the **Assessment report templates** panel, click **Add new template**, drop in the `.docx`, and give it a template name. The name is what analysts pick from at export time.
On any assessment, open the actions menu and choose **Export**, then **Export as Word**. Pick the template, confirm the file name, and click **Build Report**. Generation runs in the background: the dialog shows progress and offers **Download Report** when it is done, and you get a notification if you have notifications enabled. The export options stay disabled while the assessment is still collecting documents or being analyzed, and for anyone without permission to export assessments.
Only `.docx` is accepted, up to 100 MiB. `.doc`, `.dotx`, `.rtf`, and PDF uploads are rejected. If Word reports your file as `.docx` but the upload still fails, open it in Word and re-save as `.docx`; files renamed from another format fail the content check.
## Placeholder syntax
Every placeholder is double braces around an entity, a `::` separator, and a field name.
```text theme={null}
{{entity::field name}}
```
```text expandable theme={null}
{{vendor::name}}
{{vendor::description}}
{{assessment::residual risk}}
{{assessment::completed at}}
{{services::inherent risk}}
{{reviews::outcome}}
{{vendor::Data Classification}}
```
Four rules govern how they are matched:
* **Case-insensitive.** `{{Vendor::Name}}` and `{{vendor::name}}` are the same placeholder.
* **Whitespace-tolerant.** `{{ vendor :: name }}` works. Leading and trailing whitespace inside the braces is trimmed.
* **Formatting-tolerant.** A placeholder still resolves when Word has split it across several runs, which happens routinely during editing. A placeholder that spans a paragraph break also resolves in ordinary body text, but not inside a table cell, so keep placeholders in tables within a single paragraph.
* **Not nestable.** `{{vendor::{{name}}}}` is not supported. Never put braces inside a placeholder.
### Entities
| Entity | Resolves to |
| - | - |
| `vendor` | The vendor the assessment belongs to |
| `assessment` | The assessment being exported |
| `services` | All services in scope on the assessment, flattened into one value per field |
| `reviews` | The whole-assessment reviews on the assessment, flattened into one value per field |
| `intelligence` | Vendor Intelligence on the vendor (company profile, financial health, security posture, registration, people and screening) and any financial statements submitted for it |
| `agent` | AI-written prose, generated from a prompt you write in the template |
| `findings` | A repeating table row, one row per finding |
Anything else is left untouched. `{{org::name}}` stays in the document verbatim, because `org` is not a supported entity.
### Custom fields
Custom fields are addressed by their configured name, lowercased. A vendor custom field called **Data Classification** is `{{vendor::data classification}}`. Custom fields are available on `vendor`, `assessment`, and `services`.
System fields win collisions. If you create a vendor custom field named "Name", `{{vendor::name}}` still resolves to the vendor's system name field.
## AI-written sections
An `{{agent::...}}` placeholder is a prompt, not a field lookup. Coverbase runs an agent against the assessment and drops its answer into the document.
```text theme={null}
{{agent::Write a two paragraph executive summary of this vendor's security posture, aimed at a non-technical audience.}}
{{agent::List the three most material risks identified in this assessment and the compensating control for each.}}
{{agent::Summarize the vendor's incident response commitments and note any gaps against our standard.}}
```
The agent is given vendor fields, assessment fields, evaluation summaries, findings, reviews, questionnaire excerpts, and the headline of each Vendor Intelligence section as preloaded context. It can call tools to fetch vendor data, assessment data, evaluation summaries, services, findings, reviews, commitments, questionnaire responses, and full Vendor Intelligence sections for anything not already loaded.
**Agent output is rendered as formatted Word content**, not as raw text. The following markdown is honored:
| Markdown | Renders as |
| - | - |
| `**bold**` | Bold run |
| `*italic*` | Italic run |
| `***bold italic***` | Bold and italic run |
| `==highlight==` | Highlighted run |
| `- item` | Bulleted list, nesting by indentation |
| `1. item` | Numbered list, nesting by indentation |
| Blank line | Paragraph break |
Headings and markdown tables are not rendered. Ask for prose and lists.
The agent inherits the **character** formatting of the run the placeholder sits in, so a placeholder in 10pt Calibri produces 10pt Calibri prose. If a bold label precedes the placeholder in the same paragraph, put the placeholder in its own non-bold run or the generated text comes out bold.
**Paragraph** properties behave differently depending on how much the agent writes:
| Agent output | Paragraph properties |
| - | - |
| A single paragraph | The host paragraph's properties are kept, including its style, indentation, and list membership |
| Multiple paragraphs or any list | Each generated block gets its own paragraph properties. Generated lists are built with their own numbering, independent of any list the placeholder sat in |
Do not put `{{agent::...}}` inside a list item and expect the generated bullets to continue that list. A prompt that returns a list produces a fresh list with its own numbering, not a continuation of the host list. Put list-producing prompts in a plain paragraph of their own.
Each agent placeholder is an independent LLM call. A template with twenty prompts costs twenty generations, runs at most eight of them concurrently, and takes correspondingly longer. Keep prompts specific and few. Identical prompt text anywhere in the template is deduplicated and answered once.
When an agent cannot answer, the document gets a short marker instead of prose:
| Marker | Meaning |
| - | - |
| `Not available` | The agent ran but found no data to answer the prompt |
| `[Generation timed out]` | The prompt exceeded the per-prompt budget of 15 minutes |
| `[Generation failed]` | The agent errored on that prompt |
| `[Agent error]` | The whole agent batch failed to start |
## Repeating findings tables
`{{findings::::}}` placeholders turn a table row into a repeating row. Build a two-row table: a header row, and one body row holding the placeholders. Coverbase clones the body row once per finding.
| ID | Title | Risk | Due |
| - | - | - | - |
| `{{findings::new::id}}` | `{{findings::new::title}}` | `{{findings::new::risk level}}` | `{{findings::new::due date}}` |
There are two sets:
| Set | Contents |
| - | - |
| `new` | Findings raised by this assessment |
| `pre_existing` | Still-open findings on the same vendor that came from somewhere else |
### One table per risk domain
Add a risk domain between the set and the column (`{{findings::::::}}`) to narrow a table to the findings whose controls belong to that domain. Use one table per domain to get a "New Information Security findings", "New Privacy findings", "New BRM findings" structure:
**Table 1: New Information Security findings**
| ID | Title | Risk |
| - | - | - |
| `{{findings::new::Information Security::id}}` | `{{findings::new::Information Security::title}}` | `{{findings::new::Information Security::risk level}}` |
**Table 2: New Privacy findings**
| ID | Title | Risk |
| - | - | - |
| `{{findings::new::Privacy::id}}` | `{{findings::new::Privacy::title}}` | `{{findings::new::Privacy::risk level}}` |
Write the domain exactly as it is named in **Configuration → Risk domains**; matching ignores case and surrounding spaces. A finding's domain comes from the control it was raised against: the control section's risk domain if it has one, otherwise the control set's. Findings not raised against a control (and controls with no domain at either level) appear in the unscoped tables only.
If you would rather keep one table and label each row, use the `risk domain` column instead:
| Title | Risk domain |
| - | - |
| `{{findings::new::title}}` | `{{findings::new::risk domain}}` |
Rules that apply to findings tables:
* **A row belongs to exactly one set.** The first set referenced in the row wins. Placeholders from the other set, or from a different risk domain, in that same row resolve to empty text, so do not mix `new` and `pre_existing`, or two domains, in one row.
* **Empty sets collapse to one row.** A set with no findings renders a single row reading "No new findings" or "No pre-existing open findings", with " for ``" appended when the table is scoped to a domain.
* **A misspelled risk domain is reported.** The table renders its empty state and the placeholder is recorded on the generated document as an unknown field, so a typo does not quietly pass as "no findings in this domain".
* **Tables anywhere are covered.** Body tables, tables nested inside cells, and tables in headers and footers all expand.
* **Only inside tables.** A `{{findings::...}}` placeholder in ordinary body text is left in the document verbatim.
* **Capped at 100 rows per set.** Larger sets are truncated.
* **Keep each placeholder in one cell.** A placeholder split across two cells is not matched.
## Signature anchors
If the report is going out for signature, place DocuSign anchor strings in the template. They pass through generation as ordinary text and are read when the signature request is created, positioning each signer's tabs at the anchor.
| Anchor | Purpose |
| - | - |
| `/sn1/` through `/sn5/` | Signature block for signer 1 through 5 |
| `/date_signed1/` through `/date_signed5/` | Date-signed tab |
| `/date1/` through `/date5/` | Date tab |
| `/full_name1/`, `/first_name1/`, `/last_name1/` | Name tabs, numbered per signer |
| `/title1/` through `/title5/` | Signer title tab |
| `/organization1/` through `/organization5/` | Signer organization tab |
Anchors are plain text in the document. Set them in white or a small font size if you do not want them visible in the final PDF.
Two things to know about how they are handled:
* **Signature anchors are recorded at generation time.** Only `/sn1/` through `/sn5/` are scanned for and stored on the generated report. The other tab anchors are read from the document when the signature request is created, so they do not need to be recorded earlier.
* **A missing anchor blocks sending.** Creating a signature request fails if a signer is assigned an anchor that is not present in the document. If you add a third signer, add `/sn3/` to the template first.
* **The number ties a tab to a signer.** `/sn2/` creates the second signer, and `/title2/` or `/date_signed2/` place that signer's tabs. A tab anchor numbered for a signer with no matching `/snN/` in the document is ignored.
## What happens to unresolved placeholders
The placeholder text stays in the document. This is deliberate: a blank space hides the problem, while a visible `{{vendor::use cases}}` tells the report author that the field is empty in Coverbase. Fill in the source data and re-export.
`{{intelligence::...}}` placeholders are the exception. An empty one renders `Not available`, because many of those fields are legitimately empty for a given vendor.
The placeholder text stays in the document, and the field is recorded on the generated document as an unknown field. This usually means a typo, or a custom field that was renamed or disabled after the template was written.
Nothing happens at all. The text is not recognized as a placeholder and passes through untouched.
The cell renders empty and the column is recorded as an unknown field. The row still repeats correctly.
## Authoring tips
* **Type placeholders in one go.** Word splits text into runs when you edit mid-word, add a spellcheck correction, or paste. Substitution handles split runs, but the cleanest way to avoid surprises is to type the whole placeholder without stopping, or paste it as plain text.
* **Avoid autocorrect damage.** Word can turn `::` or straight quotes inside a prompt into other characters. Check that a placeholder still reads exactly as you typed it.
* **Style the placeholder, not the paragraph.** A placeholder inherits the formatting of its own run. If the label before it is bold and you do not want bold output, make sure the placeholder itself is not bold.
* **Test with a real assessment.** Export against an assessment that has findings, several services, and completed reviews. Empty-state behavior differs from populated behavior.
* **Keep one template per audience.** A short executive template and a long evidence template beat one template with everything in it, because agent prompts you do not need still cost a generation.
When a previously generated report is regenerated in place rather than exported fresh, findings tables are left as they are. Findings rows are expanded on the export path only.
# Evidence packaging and the due-diligence file
Source: https://docs.coverbase.com/reporting/due-diligence-file
Produce the complete due-diligence file for one third party: the full vendor report with profile, assessments, findings, contracts, obligations, documents, monitoring, notes and the audit trail, plus bulk document archives and structured exports.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
An examiner, an internal auditor or an acquirer asks the same question: show me everything you hold on this third party, and show me how you decided. Coverbase answers it from the vendor record itself, without anyone assembling a folder by hand.
## The full vendor report
From a vendor's page, open **Actions** and choose **Build report** to build a single branded PDF of the whole relationship. Choose the report type and the sections, and Coverbase builds it in the background and notifies you when it is ready. Building a report needs permission to export vendors across the organization, and the redesigned vendor and service reports are enabled per workspace: if **Build report** is missing, ask your Coverbase contact.
Risk posture, profile and the latest assessment outcome. A few pages, for a committee pack.
Adds services, assessments, findings, contracts, obligations and documents.
**Everything**, including the bill of materials, notes, and the complete audit trail.
A full vendor report carries, in one document:
| Section | What it contains |
| - | - |
| Vendor profile | Identity, corporate registration, description, use case, owners, tier and criticality |
| Risk profile | Scores by risk domain, the scale each was rated on, and the inherent-risk basis |
| Services and engagements | Each service, its business use, its own risk profile and its owners |
| Assessments | Every assessment run against the vendor, its scope, outcome, approval option and reviewer |
| Findings | Open and closed findings, severity, owner, and remediation state |
| Contracts | The contract family, key terms, dates and values |
| Obligations | Contractual obligations extracted and tracked, with status |
| Documents | The document inventory: what was collected, when, and from where |
| Monitoring | Radar signals raised against the vendor and how each one was closed out |
| Performance | Vendor performance scoring where enabled |
| Procurement | Purchase orders and procurement records |
| Bill of materials | Components and fourth parties behind the service |
| Notes | The comment timeline, in order |
| Audit trail | Every recorded action on the record, with actor and timestamp |
The report carries **your** brand: your logo and accent color in the running header, the vendor's mark on the masthead, and your third-party contact address in the footer. It is a document you can hand to a regulator without reformatting it.
The same three-tier export exists at **service** level, for programs that diligence per service rather than per legal entity, and at **assessment** level for a single review cycle.
## Everything else in the package
Select the vendor's documents and download them as a single `.zip`: SOC 2 reports, certificates, policies, questionnaire attachments, signed contracts, and anything else collected. The archive builds in the background and lands in your documents when it is ready. Bulk document export is org-scoped and gated on an export permission, so it is deliberately not something an assigned-only reader can trigger.
A full assessment PDF adds per-control evidence: the evaluation, the citation, the evidence snippet images, the reviews, follow-ups, notes and the activity log for that assessment. This is the layer that shows *how* a control was judged, not only what the judgment was. See [Reporting overview](/reporting/overview).
Upload your firm's house report as a `.docx` with placeholders, and Coverbase fills it per assessment from live data, including AI-answered narrative sections. Your layout, your headings, your language. See [Assessment report templates](/reporting/assessment-report-templates).
**Export as Excel** in the same **Actions** menu builds a workbook of the vendor, one sheet per module of the vendor page: an overview, services, engagements, assessments, findings, contracts, obligations, documents, monitoring, performance and SLAs, procurement, notes and activity. Where the PDF caps each table so one record cannot dominate the read, the workbook carries every row, for filtering and sampling.
Org-level `.xlsx` exports cover many assessments at once: a filtered list of assessments, or every assessment result within a date range, for the population testing an examiner asks for rather than one file at a time.
The [Export API](/export-api-concepts) returns vendors, services, assessments, evaluations, controls, findings, obligations and contracts as JSON, filtered and paginated, so a package can be assembled on a schedule into your GRC platform, warehouse or regulator submission pipeline.
`GET /v1/system_audit_log` returns the organization-wide record of every action, including public-API calls and AI assistant tool calls, filterable and exportable. See [Audit trails](/security/audit-trails).
## Assembling an examination package
Filter the vendor list to the population in scope: critical activities, a business line, a tier, a data classification, a jurisdiction, or a custom field of your own. Save it as a view so the same population reproduces next time.
Run the bulk assessment `.xlsx` for the date range under examination. This is the sampling frame.
For each vendor the examiner picks, export the **Full** vendor report and the document archive. Between them they carry the profile, the diligence, the decisions, the paper, the monitoring, and the audit trail.
Your control sets, your workflow definitions, your roles and their permission matrices, and the [regulatory alignment](/security/regulatory-alignment) mapping, which shows what the program was designed against.
Run this once before you need it. The week an examination opens is a bad time to find out what the package does and does not contain.
## Related
Every reporting surface and which one to use.
What the package is evidencing, mapped to the guidance.
The structured, programmatic path.
The record behind every decision in the package.
# Reporting overview
Source: https://docs.coverbase.com/reporting/overview
How Coverbase turns assessment data into deliverable documents: custom Word report templates, standard exports, and the placeholder system that fills them.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Coverbase produces two kinds of assessment deliverable. Standard exports give you a fixed, complete dump of an assessment. Custom Word report templates give you a document that looks exactly like your firm's house report, filled in automatically from live assessment data.
## Reporting surfaces
Upload a `.docx` file containing placeholders. Coverbase clones it per assessment, substitutes vendor, assessment, service, review, and finding data, and returns a finished Word document.
Every placeholder you can write in a template, what it resolves to, and how it is formatted.
A fixed-layout PDF of a single assessment, no template required. Choose an executive summary, standard, or full export, and toggle sections such as findings, reviews, follow-ups, notes, evidence snippet images, and the activity log.
One assessment's evaluations as `.xlsx` or `.csv`, from **Export as Excel** or **Export as CSV** on the assessment. Toggle the executive summary, follow-ups, notes, activity log, SLA timings and reviews. The `.xlsx` can also carry a sheet of the evidence behind each evaluation.
Org-level `.xlsx` exports covering many assessments at once: a filtered list of assessments, or every assessment result within a date range. These are not per-assessment exports and have no section toggles.
Pull the underlying assessment, evaluation, and finding objects as JSON and build reporting in your own BI or GRC stack.
The complete file for one third party: a full vendor report covering profile, assessments, findings, contracts, obligations, documents, monitoring, notes and the audit trail, plus the document archive behind it.
## Which one to use
| You want | Use |
| - | - |
| A branded, client-ready report with your own narrative sections and layout | [Custom Word report template](/reporting/assessment-report-templates) |
| A complete record of everything in one assessment, including evidence snippets and the activity log | Standard PDF export, full mode |
| One assessment's evaluations and evidence in a spreadsheet | Assessment spreadsheet export |
| Many assessments in a spreadsheet for filtering or pivoting | Bulk `.xlsx` export |
| Assessment data in your own warehouse, dashboard, or regulator submission pipeline | [Export API](/export-api-concepts) |
| Everything you hold on one third party, for an examiner, an auditor, or an acquirer | [Due-diligence file](/reporting/due-diligence-file) |
## How a custom report is generated
A `.docx` file with placeholders is uploaded once, from the **Assessment report templates** panel in **Configuration > Assessment Settings > Reports**, and reused across assessments.
From the assessment page, choose **Export**, then **Export as Word**, and pick the template and a filename. The request returns immediately with a document ID; generation runs as a background job.
Static placeholders are read straight from the database. `{{agent::...}}` placeholders are answered by an LLM that has the assessment loaded as context. Findings table rows are cloned once per finding.
The generated `.docx` is stored as an org document. The export dialog tracks progress and offers the download when the job completes.
Custom Word report templates are gated per organization. If the export option is not visible on the assessment page, an admin needs to turn on **Assessment report templates** in **Configuration > Assessment Settings > Reports**. If it is visible but disabled, the assessment has no results to export yet (it is still collecting documents or being analyzed), or your role lacks permission to export assessments.
## Terminology
The mechanism has a few names in the wild. This documentation uses **placeholder** throughout.
| Term | Where you will see it |
| - | - |
| Placeholder | This documentation, and the stored `placeholder_values` map on a generated report |
| Template variable | The in-app help text on the template upload dialog |
| Token | The [Admin and setup guide](/user-guides/admin-setup), in the report templates step |
| Tag, merge field, mustache | Common informal names, since the syntax borrows `{{ }}` from Mustache |
The syntax resembles Mustache but is not Mustache. There are no sections, no partials, no inverted blocks, and no nesting. Everything Coverbase supports is listed in the [placeholder reference](/reporting/template-placeholders).
# Template placeholder reference
Source: https://docs.coverbase.com/reporting/template-placeholders
Every placeholder available in a Coverbase Word report template, what it resolves to, and how the value is formatted.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
This is the complete list of placeholders you can write in an [assessment report template](/reporting/assessment-report-templates). Field names are matched case-insensitively, and whitespace around the entity, the `::`, and the field name is ignored.
The same list is in the product: **Variables Catalog** in the **Add new assessment report template** dialog shows every placeholder with its exact spelling, including your organization's enabled custom fields, and copies one when you click it.
## Vendor
`{{vendor::}}` resolves against the vendor that the assessment belongs to.
| Placeholder | Value |
| - | - |
| `{{vendor::name}}` | Vendor name |
| `{{vendor::description}}` | Vendor description |
| `{{vendor::location}}` | Vendor headquarters location |
| `{{vendor::use cases}}` | The vendor's use case text |
| `{{vendor::relationship owners}}` | Comma-separated display names of the relationship owners |
| `{{vendor::risk analysts}}` | Comma-separated display names of the risk analysts |
| `{{vendor::watchers}}` | Comma-separated display names of the watchers |
| `{{vendor::dri}}` | The vendor service requestor recorded on the vendor |
| `{{vendor::}}` | Any enabled vendor custom field, addressed by its name |
## Assessment
`{{assessment::}}` resolves against the assessment being exported. Dates are formatted `YYYY-MM-DD` in the timezone supplied at export time.
| Placeholder | Value |
| - | - |
| `{{assessment::residual risk}}` | Residual risk level name. Falls back to `Low` when no level is set |
| `{{assessment::inherent risk}}` | Inherent risk level name |
| `{{assessment::assignee}}` | Display name of the assignee |
| `{{assessment::approval option}}` | Label of the selected approval option |
| `{{assessment::completed at}}` | Date the assessment was completed |
| `{{assessment::next vendor assessment}}` | The vendor's next assessment date, or `Never` when reassessment is disabled |
| `{{assessment::recommendation}}` | `Status: recommendation text`, using whichever parts are present |
| `{{assessment::assessment score}}` | Average score, else percent score with a `%` suffix, else summed score, to one decimal place |
| `{{assessment::vendor documents}}` | Bulleted list of the non-archived supporting document names |
| `{{assessment::summary}}` | The assessment summary body, flattened to plain text. Markdown headings become uppercase lines and list markers become bullets |
| `{{assessment::open issues}}` | Bulleted list of open issues as `# ` |
| `{{assessment::<custom field name>}}` | Any enabled assessment custom field, addressed by its name |
## Services
`{{services::<field>}}` covers **all** services in scope on the assessment, flattened into a single value.
When the assessment has one service, the value is the bare field value. When it has more than one, the value becomes a bulleted block of `• Service name - value`, and services with no value for that field are dropped. When the assessment has no services, every services placeholder is empty.
| Placeholder | Value |
| - | - |
| `{{services::name}}` | Comma-separated list of service names. This one is always comma-separated, never bulleted |
| `{{services::description}}` | Service descriptions |
| `{{services::inherent risk}}` | Inherent risk level name per service |
| `{{services::relationship owners}}` | Relationship owners per service |
| `{{services::watchers}}` | Watchers per service |
| `{{services::next assessment date}}` | Next assessment date per service, or `Never` |
| `{{services::<custom field name>}}` | Any enabled service custom field, addressed by its name |
## Reviews
`{{reviews::<field>}}` covers the whole-assessment reviews on the assessment. Domain-scoped reviews from the risk profile are excluded, matching the other exports.
Formatting follows the same rule as services: a single review renders bare, several reviews render as a bulleted block keyed by a row label. The row label is the review name, falling back to the reviewer, falling back to `Review 1`, `Review 2`, and so on.
| Placeholder | Value |
| - | - |
| `{{reviews::summary}}` | One self-contained line per review, `<label> - <outcome>: <notes>`. Outcome falls back to `Pending` |
| `{{reviews::reviewer}}` | Reviewer per review |
| `{{reviews::status}}` | Review status label |
| `{{reviews::outcome}}` | Review outcome label, or `Pending` while undecided |
| `{{reviews::description}}` | Review description |
| `{{reviews::notes}}` | Reviewer notes |
| `{{reviews::decided}}` | Date the review reached its outcome. An undecided review has no date |
| `{{reviews::last updated}}` | Date the review was last updated |
<Tip>
Use `{{reviews::summary}}` when there is more than one reviewer. The individual field placeholders each produce their own bulleted list, so reading a reviewer's outcome next to their notes means cross-referencing two lists. `summary` keeps each reviewer's label, outcome, and notes on one line.
</Tip>
## Vendor Intelligence
`{{intelligence::<field>}}` resolves against Coverbase's outside-in research on the vendor -- the data behind the Vendor Intelligence tabs -- plus any financial statements your organization has submitted for that vendor.
These are stored values, so they resolve exactly, without a model call. Prefer them over `{{agent::...}}` for any figure that is a fact rather than a judgement: a placeholder cannot get a market capitalization wrong.
Every `{{intelligence::...}}` placeholder resolves to something. A field with no value for this vendor (a private company has no market capitalization) renders `Not available` rather than staying in the document as placeholder text. So does a field from a Vendor Intelligence surface your organization is not entitled to.
### Company and market
| Placeholder | Value |
| - | - |
| `{{intelligence::industry}}` | Industry on the vendor's company profile |
| `{{intelligence::headquarters}}` | Headquarters location |
| `{{intelligence::founded}}` | Founding year |
| `{{intelligence::employees}}` | Employee count |
| `{{intelligence::revenue}}` | Most recent fiscal year revenue |
| `{{intelligence::public or private}}` | Whether the company is publicly traded |
| `{{intelligence::market capitalization}}` | Market capitalization, abbreviated (for example, `$12.2B`) |
| `{{intelligence::ticker}}` | Stock ticker symbol |
| `{{intelligence::exchange}}` | Exchange the company is listed on |
| `{{intelligence::total funding}}` | Total disclosed funding raised |
### Financial health
| Placeholder | Value |
| - | - |
| `{{intelligence::financial health score}}` | Coverbase Financial Health Score out of 100 |
| `{{intelligence::financial health band}}` | Risk band the score falls in |
| `{{intelligence::financial health confidence}}` | Confidence tier behind the score (`A`, `B` or `C`) |
| `{{intelligence::financial health as of}}` | Date the score was computed as of |
### Security posture
| Placeholder | Value |
| - | - |
| `{{intelligence::security rating}}` | Grade and score together, for example, `B (78/100)` |
| `{{intelligence::security grade}}` | Letter grade alone |
| `{{intelligence::security score}}` | Score out of 100 |
| `{{intelligence::security next steps}}` | Recommended actions from the scan, most urgent first, joined with semicolons |
| `{{intelligence::security change since last scan}}` | What moved since the previous scan in one line, for example, `since 2026-08-12: score -6, 2 new findings, 1 new CVE` |
| `{{intelligence::trust center}}` | URL of the vendor's trust center |
### Corporate registration
| Placeholder | Value |
| - | - |
| `{{intelligence::legal name}}` | Official registered name from the corporate registry |
| `{{intelligence::registration status}}` | Registration standing |
| `{{intelligence::jurisdiction}}` | Jurisdiction the company is registered in |
| `{{intelligence::incorporation date}}` | Date of incorporation |
| `{{intelligence::lei}}` | Legal Entity Identifier |
| `{{intelligence::duns}}` | Dun & Bradstreet DUNS number |
| `{{intelligence::company number}}` | Local business register company number |
| `{{intelligence::cik}}` | SEC EDGAR Central Index Key |
### People, reputation and screening
| Placeholder | Value |
| - | - |
| `{{intelligence::leadership}}` | Confirmed executives and board members, comma-separated |
| `{{intelligence::adverse media}}` | `None found`, `Not searched`, or a count. Never reports an unsearched vendor as clear |
| `{{intelligence::bbb rating}}` | Better Business Bureau rating |
| `{{intelligence::trustpilot rating}}` | Trustpilot rating |
| `{{intelligence::screening status}}` | Sanctions and adverse-media screening result for the vendor: `Not enrolled`, `Screened, no matches`, or the number of matches and how many await review |
### Submitted financial statements
These resolve only when your organization has [uploaded financial statements](/products/vendor-intelligence) for the vendor. The metric blocks each render one line per metric, with both fiscal years and the change between them.
| Placeholder | Value |
| - | - |
| `{{intelligence::financial statements}}` | Classification of the submitted statements, for example, `Audited - Unqualified Opinion` |
| `{{intelligence::financial risk rating}}` | Credit policy risk rating derived from the statements |
| `{{intelligence::statement legal entity}}` | Legal name of the entity that issued the statements |
| `{{intelligence::auditor}}` | Audit firm that signed the opinion |
| `{{intelligence::period covered}}` | Fiscal periods the statements cover |
| `{{intelligence::net worth}}` | Net worth for the most recent submitted fiscal year |
| `{{intelligence::ebitda}}` | EBITDA for the most recent submitted fiscal year |
| `{{intelligence::free cash flow}}` | Free cash flow for the most recent submitted fiscal year |
| `{{intelligence::policy metrics}}` | The four credit policy metrics with their ratings and figures |
| `{{intelligence::balance sheet metrics}}` | Working capital, current, quick and cash ratios, debt, debt to equity, net worth, asset turnover, return on assets, return on equity |
| `{{intelligence::income statement metrics}}` | Revenue, EBIT, EBITDA, debt to EBITDA, margins, net income, EPS, inventory and AR turnover |
| `{{intelligence::cash flow metrics}}` | Free cash flow and change in cash |
| `{{intelligence::leverage ratios}}` | Debt to capitalization, equity multiplier, degree of financial leverage |
<Note>
A figure the statements do not report renders as `Not reported`, never as `0`. A zero would read as a measured result, which is a different claim about the vendor.
</Note>
## Findings
`{{findings::<set>::<column>}}` only works **inside a table row**. The row is cloned once per finding in the set. See [repeating findings tables](/reporting/assessment-report-templates#repeating-findings-tables) for how to lay the table out, and [one table per risk domain](/reporting/assessment-report-templates#one-table-per-risk-domain) to split findings by risk domain.
Sets:
| Set | Contents |
| - | - |
| `new` | Findings raised by this assessment |
| `pre_existing` | Still-open findings on the same vendor that did not come from this assessment |
Columns, usable with either set:
| Column | Value |
| - | - |
| `id`, `public id`, `public idx` | The finding's public reference number |
| `title` | Finding title |
| `description` | Finding description, including recommendations |
| `status` | Finding status |
| `due date` | Due date, `YYYY-MM-DD` in the export timezone |
| `risk level` | Risk level from the risk matrix (urgency by severity) |
| `risk severity` | Criticality tier derived from the control's maximum score |
| `severity` | Severity set by the reviewer |
| `urgency` | Urgency set by the reviewer |
| `assignee`, `assigned to` | Display name of the assignee |
| `created by` | Display name of the creator |
| `control`, `control expectation` | The control expectation the finding was raised against |
| `risk domain`, `risk domains` | Risk domain of the control the finding was raised against. Comma-separated when the finding spans controls in several domains |
| `score` | Score level name |
| `resolution timeline` | Days allowed to resolve a finding at this risk level, from your findings settings, as a number |
Rows where a column has no value render that cell empty. Each set is capped at 100 rows.
### Scoping a table to one risk domain
`{{findings::<set>::<risk domain>::<column>}}` narrows a table to the findings whose controls belong to one risk domain, so a report can carry a separate table per domain:
```text theme={null}
{{findings::new::Information Security::title}}
{{findings::new::Privacy::title}}
{{findings::pre_existing::BRM::title}}
```
The domain is the name as configured in **Configuration → Risk domains**, matched ignoring case and surrounding spaces. It resolves per finding through the control the finding was raised against: the control section's risk domain when it sets one, otherwise the control set's. A domain with no findings renders "No new findings for Privacy"; a domain your org does not have is reported as an unknown placeholder.
## Agent
`{{agent::<your prompt>}}` generates prose from the assessment. The whole text after `::` is the prompt.
The agent reads the assessment, its findings, evals, reviews, services and commitments, and questionnaire responses, and the headline of every Vendor Intelligence section -- company profile, financial health, security posture, corporate registration, people, reputation, compliance and legal, products, and sanctions screening. It can pull any of those sections in full when a prompt needs the evidence behind a headline.
Use a placeholder rather than the agent for anything that is a stored value. The agent is for judgement: a conclusion, an overview, a paragraph weighing several facts together.
```text theme={null}
{{agent::Write a short executive summary of this assessment for a board audience.}}
```
Output is rendered as Word content, honoring `**bold**`, `*italic*`, `***bold italic***`, `==highlight==`, and bulleted and numbered lists. Headings and markdown tables are not rendered. See [AI-written sections](/reporting/assessment-report-templates#ai-written-sections) for the full behavior, including timeout and failure markers.
## Custom field formatting
Custom fields render according to their configured type.
| Field type | Renders as |
| - | - |
| Text | The stored text |
| Number | Comma-grouped, with up to two decimal places and none on whole numbers, so `1000` renders as `1,000`. Fields configured as currency render as USD, so `1234.56` becomes `$1,234.56` |
| Date | `YYYY-MM-DD` in the export timezone |
| Boolean | The literal words `True` and `False` |
| User | Comma-separated display names of the selected users |
| Select | Every option listed, with `✅` on the selected one and `◻️` on the rest |
| Multi-select | Every option listed, with `✅` on each selected one and `◻️` on the rest |
<Note>
Select and multi-select fields with more than 10 options collapse to a plain comma-separated list of only the selected values. A marked list of 70 country options is unreadable in a report, so Coverbase drops the unselected ones automatically.
</Note>
## Quick lookup
<AccordionGroup>
<Accordion title="I need the vendor's name and description" icon="building">
`{{vendor::name}}` and `{{vendor::description}}`.
</Accordion>
<Accordion title="I need the risk rating that came out of this assessment" icon="gauge">
`{{assessment::residual risk}}` for the outcome, `{{assessment::inherent risk}}` for the starting point, `{{assessment::assessment score}}` for the numeric score.
</Accordion>
<Accordion title="I need a table of the issues we raised" icon="table-list">
A two-row table with `{{findings::new::id}}`, `{{findings::new::title}}`, `{{findings::new::risk level}}`, and `{{findings::new::due date}}` in the body row.
</Accordion>
<Accordion title="I need a separate issues table for each risk domain" icon="layer-group">
One table per domain, each using `{{findings::new::<risk domain>::<column>}}`, for example `{{findings::new::Privacy::title}}`. Or keep one table and add a `{{findings::new::risk domain}}` cell to label each row.
</Accordion>
<Accordion title="I need the approver and their decision" icon="user-check">
`{{reviews::summary}}` for everything on one line per reviewer, or `{{assessment::approval option}}` for the approval decision recorded on the assessment itself.
</Accordion>
<Accordion title="I need the vendor's financial or security ratings" icon="chart-line">
`{{intelligence::financial health score}}`, `{{intelligence::financial health band}}` and `{{intelligence::security rating}}`. For a credit memo built on submitted statements, `{{intelligence::financial risk rating}}` and the metric blocks.
</Accordion>
<Accordion title="I need the vendor's registered legal name" icon="building-columns">
`{{intelligence::legal name}}`, with `{{intelligence::jurisdiction}}` and `{{intelligence::incorporation date}}` beside it.
</Accordion>
<Accordion title="I need a narrative paragraph that is not a field" icon="wand-magic-sparkles">
`{{agent::...}}` with a specific prompt. Say who the audience is and how long the answer should be.
</Accordion>
</AccordionGroup>
# AI governance
Source: https://docs.coverbase.com/security/ai-governance
How we select, test, and constrain the AI models that power Coverbase, and how we handle your data.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Coverbase uses AI to read evidence, draft assessments, extract contract clauses, and surface risk. Because those outputs feed real risk decisions, we govern the AI the same way we govern the rest of the platform: with deliberate model selection, testing, human oversight, and strict data handling.
## Model selection and hosting
<CardGroup>
<Card title="Enterprise-grade models" icon="microchip">
We run Anthropic Claude models (the Sonnet, Haiku and Opus families) and Amazon Titan embeddings through enterprise model hosting (AWS Bedrock) in our own AWS account, rather than calling consumer endpoints.
</Card>
<Card title="No training on your data" icon="shield-halved">
Customer data sent to the models we use is not used to train those foundation models. Your data is used to serve your requests, not to improve a third party's model.
</Card>
</CardGroup>
Two details worth knowing when you map this to a residency or data-flow review:
* **Cross-region inference.** Most Claude calls use Bedrock's global cross-region inference profiles, so AWS can serve an individual inference request from capacity in an AWS region other than the one Coverbase runs in (see [Data residency](/security/data-protection#data-residency)).
* **Web research.** Features that research a vendor on the public web, such as control evaluations with web search and company and financial lookups, send search queries built from what they are looking up (for example the vendor's name and the topic) to external web search providers, Tavily and Perplexity.
Bedrock model-invocation logging is configured for metadata only (model, timing, token counts), so prompt and response text is not written to those logs.
## Testing and evaluation
AI behavior is tested, not assumed. We treat model-driven features as systems that must be measured before and after they change.
* **Evaluations.** Model-driven features are exercised against evaluation suites so we can measure output quality and catch regressions when prompts or models change.
* **Confidence signals.** Where the model produces a judgment, we surface internal confidence signals to reviewers so low-confidence outputs get extra scrutiny.
* **Pre-release validation.** Prompt and model changes go through the same reviewed [secure-development](/security/secure-development) pipeline as the rest of the platform.
## Human oversight
<CardGroup>
<Card title="Human in the loop" icon="user-check">
AI generates and proposes; people decide. Assessment scoring, findings, and analyst commentary remain reviewable and editable by your team before they become part of the record.
</Card>
<Card title="Explicit confirmation for AI writes" icon="hand">
Through the MCP server, every AI-initiated action that creates, updates, or deletes data requires explicit confirmation: the assistant cannot silently mutate your data. See [MCP security](/mcp/security#write-action-protection).
</Card>
</CardGroup>
## Guardrails and data handling
* **Permission inheritance.** AI assistants connected through MCP act with the connected user's permissions and cannot exceed them. See [MCP permissions](/mcp/permissions).
* **Scoped context.** User-provided context is bounded before it is sent to a model (inputs are truncated to conservative limits), and prompts are structured to keep instructions and data clearly separated.
* **Tenant boundary preserved.** Model-driven features operate within the same per-organization isolation as everything else; AI cannot reach across tenants. See [Tenant isolation](/security/data-protection#tenant-isolation).
## Redacting personal data before model calls
Organizations with the third-party lifecycle features can turn on **Redact personal data before model calls** on the [Agent Ledger](/products/agent-ledger) page. It is off by default.
* **What is redacted.** Email addresses, phone numbers, IBANs, US tax IDs, and the full names of your organization's users and your vendors' contacts are replaced with placeholders such as `[[PERSON:1a2b3c4d5e6f]]` before the request reaches the model. The placeholder is a keyed hash (HMAC) under a random secret held for your organization and never returned by any route, so the same person gets the same placeholder across calls, and a placeholder cannot be reversed by guessing values, even for short ones such as phone numbers or tax IDs.
* **What comes back.** The model is told to reproduce placeholders verbatim, and the response is restored before anyone sees it. Only placeholders the redactor issued are restored.
* **Enforced in one place.** Redaction runs in the connection to the model provider, not in each feature, so every model call your organization makes passes through it: the model request types for invoking a model, conversing, streaming, counting tokens, guardrails, and knowledge-base generation.
* **Fail closed.** If Coverbase cannot read whether redaction is on for your organization, the call fails rather than going out unredacted. A model request type redaction does not cover fails while redaction is on, so a new kind of call cannot slip past it.
* **What is not redacted.** The contents of images and attached documents (for example a PDF sent to the model as a document, or a file the model provider reads from storage itself), and the search query of a knowledge-base retrieval, which runs against your organization's own knowledge base. Bank and tax identifiers stored on supplier records are sealed per field (see [Field-level encryption](/security/data-protection#field-level-encryption)) and never reach a prompt in clear, whether or not redaction is on.
Each Agent Ledger row records how many personal details were redacted for that action.
## The Agent Ledger and agent policies
The [Agent Ledger](/products/agent-ledger) records every action an AI agent takes on your data: which agent, what it did, to which record, what it read and cited, its confidence, which models it called, the redaction count, and what a person decided. Recording never blocks the action, and a failed action is recorded as failed. Anyone who can read organization settings can export the actions matching a filter, up to 50,000, as a CSV prepared in the background for an audit.
Agent policies say what agents may do without a person, and each is checked where the agent acts, against the current setting. Two are enforced today: re-timing monitoring plans from Radar signals (off by default) and proposing diligence reuse at the Front Door (on by default). With a policy off, the agent does not act, and the ledger records what it held back. A policy with no agent behind it stays off and cannot be switched on, so a switch never promises a behavior nothing performs. Accepting risk or closing an issue is locked: it always needs a person.
## Learning from your reviewers
An organization can let its own reviewers' corrections calibrate its control evaluations. It is off by default and applies to that organization only.
* A daily job turns each evaluation a reviewer overturned in the last 180 days into an example for that control. An admin can switch any example off.
* With learning on, a control's evaluation receives up to five of its enabled examples and the organization's evaluation guidance, truncated, escaped and marked as reference data rather than instructions.
* With learning off, evaluations use the baseline prompt unchanged.
* Nothing learned from one organization reaches another organization's evaluations, and nothing is used to train a foundation model.
## Transparency
<Card title="What we log and don't retain" icon="list-timeline" href="/mcp/security">
AI tool calls are logged to your audit trail with user identity, parameters, and outcome. We do not retain the prompts, conversation context, or assistant responses from MCP sessions. See [MCP security and privacy](/mcp/security).
</Card>
# Audit trails
Source: https://docs.coverbase.com/security/audit-trails
Every action across the dashboard, API, and AI is logged in an audit trail you can read in the dashboard and export through the API.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Coverbase records what happened, who did it, and when, across the dashboard, the public API, and AI assistants. You can review it in the UI and pull it programmatically through the audit API, so it can flow into your SIEM, your GRC platform, or your own evidence packages.
## Two audit surfaces
Coverbase keeps audit data on two complementary surfaces, backed by the same underlying activity store:
<CardGroup>
<Card title="System-wide audit log" icon="building-shield">
Administration and configuration changes across the whole organization: sign-ins, user management, settings, integrations, controls, questionnaires, and Radar configuration. Reviewed under **Configuration → Audit Logs**, exportable to Excel, and readable via `GET /v1/system_audit_log`.
</Card>
<Card title="Per-object activity trails" icon="list-check">
The change history of an individual record: a vendor, assessment, finding, contract, and so on. Shown on each record's activity feed in the dashboard, readable via `GET /v1/activity`, and queryable by AI assistants through the MCP server.
</Card>
</CardGroup>
Both surfaces are scoped to your organization. No audit data crosses organization boundaries.
## What is captured
<CardGroup>
<Card title="Sign-ins and sign-outs" icon="key">
Session lifecycle events from the identity provider are recorded per organization, including the user's email, client IP address, user agent, and browser.
</Card>
<Card title="User management" icon="users-gear">
User creation, invitations (sent, accepted, revoked), profile updates, role changes, deactivation, and deletion.
</Card>
<Card title="Configuration changes" icon="sliders">
Creates, updates, and archives across organization settings, statuses, tags, templates, scales, risk domains, custom fields, departments, terminology, notification settings, workflows, intake configuration, and import/export runs.
</Card>
<Card title="Controls, questionnaires, and Radar" icon="file-shield">
Control and control-set changes, questionnaire question lifecycle, and Radar source, detector, and alert configuration changes.
</Card>
<Card title="Public-API calls" icon="code">
Every authenticated `/v1/*` call is recorded as an `external_api_call`, capturing the method, route, status, and the key that made it. See [Public-API audit records](#public-api-audit-records).
</Card>
<Card title="Integration and key lifecycle" icon="plug">
API keys, MCP API keys, external integrations, and API sources: added, updated, and deactivated.
</Card>
</CardGroup>
<Note>
**Exporting the audit log is itself audited.** Every Excel export from the audit log page is recorded as an `audit_log_exported` event, including the number of rows exported, so reviewing the trail leaves a trail.
</Note>
## Event groups and event types
Every system audit event carries a machine-readable **event type** and rolls up into one of eight **event groups**, which drive the filters in the dashboard and the API:
| Event group | Event types |
| - | - |
| **Access** | `app_login`, `app_logout` |
| **User management** | `user_created`, `user_invited`, `user_invitation_accepted`, `user_updated`, `user_role_changed` |
| **Configuration** | `config_created`, `config_updated`, `notification_updated`, `audit_log_exported`, `report_exported` |
| **Radar** | `radar_alert_updated`, `radar_source_created`, `radar_source_updated`, `radar_detector_created`, `radar_detector_updated` |
| **Integrations** | `integration_added`, `integration_updated` (covers API keys, MCP keys, external integrations, and public-API calls) |
| **Controls** | `control_created`, `control_updated` |
| **Questionnaires** | `question_created`, `question_updated`, `question_deleted` |
| **Archive** | `user_invitation_revoked`, `user_deactivated`, `user_deleted`, `config_archived`, `integration_deactivated`, `control_archived` |
The **Archive** group collects every deactivation, archival, and deletion event across all categories, so destructive changes can be reviewed in one place.
`GET /v1/system_audit_log/metadata` returns this taxonomy programmatically. Use it to populate filter pickers or keep an export pipeline in sync as new event types are added.
## What each record contains
Every audit record includes:
| Field | Description |
| - | - |
| `created_at` | Unix timestamp of the event. |
| `actor` | The acting user (ID, name, email, avatar). System-generated events have no actor and display as **System**. |
| `event_type` / `event_group` | The classification described above. |
| `target_type` / `target_id` | What kind of object was affected and which one (for example, a specific control, user, or tag). |
| `summary` | A human-readable one-line description of the event. |
| `data` | Structured detail: field-level diffs for updates (field name, old value, new value) and the initial values for creations. |
Two details worth knowing about the `data` payload:
* **Updates are recorded as field-level diffs**: you can see exactly which fields changed and their before/after values, not only that "something was updated."
* **Sign-in events carry session forensics**: the user's email, client IP address, user agent, and browser, sourced from the identity provider's session events.
## Reviewing the audit log in the dashboard
The system-wide audit log lives at **Configuration → Audit Logs**. By default it shows **all event groups** for the **last 30 days**, newest first; nothing is hidden by default.
<Steps>
<Step title="Filter">
Narrow by time range (last 24 hours, 7/30/90 days, all time, or a custom date range), by one or more event groups, by specific event types, or with free-text search. Search matches actor names, event summaries, and understands terms like "created", "updated", "exported", "system", and group names. Filters apply across **all** matching events, not only the visible page.
</Step>
<Step title="Inspect">
Each row shows the time, actor, event badge, target, and a details column with the field-level diff or creation values.
</Step>
<Step title="Export">
**Export Excel** downloads every event matching the current filters (not only the current page) as a spreadsheet with timestamp, actor, event group, event type, target, summary, and details columns. The export is recorded in the log as `audit_log_exported`.
</Step>
</Steps>
Results are paginated (25-250 rows per page, 50 by default), with summary cards showing the total number of matching events.
### Who can see it
Access to the audit log is governed by your organization's roles. For organizations using custom roles, the **Audit trail** resource carries `read` and `export` permissions and is always organization-wide; it cannot be scoped to assigned records. Headless access uses an `ak_*` API key carrying the `audit:read` scope (see below).
## Reading the audit log through the API
For SIEM ingestion and scheduled exports, read the system audit log programmatically:
```bash theme={null}
curl "https://api.coverbase.app/v1/system_audit_log?start_ts=1748736000&event_groups=access&event_groups=user_management&limit=500" \
-H "Authorization: Bearer ak_live_xxx" # key must carry the audit:read scope
```
### `GET /v1/system_audit_log`
| Parameter | Description |
| - | - |
| `start_ts` / `end_ts` | Unix timestamps (seconds) bounding the window. |
| `event_groups` | Repeatable: one or more of the groups above. |
| `event_types` | Repeatable: one or more specific event types. |
| `search` | Free-text search, same semantics as the dashboard search box. |
| `limit` | Page size, 1-500 (default 100). |
| `offset` | Pagination offset (default 0). |
Responses are ordered newest first and include `X-Total-Count` and `Content-Range` headers for paging through the full result set.
### Companion endpoints
* **`GET /v1/system_audit_log/metadata`**: the event group and event type taxonomy with display labels.
* **`POST /v1/system_audit_log/export_ack`**: records an `audit_log_exported` event; the dashboard calls this after every Excel export. If you build your own export tooling, call it too so exports stay visible in the trail.
### Authentication for the audit API
The audit read endpoints accept **either** of:
* a **dashboard session JWT**, subject to your organization's role permissions, or
* an **`ak_*` API key carrying the [`audit:read` scope](/conventions#api-key-scopes)**, for headless export pipelines.
<Tip>
Mint a dedicated, scope-limited key for your log-export pipeline. A key that only needs to read the audit log should carry **only** `audit:read` and nothing else, following least privilege. See [API key scopes](/conventions#api-key-scopes).
</Tip>
## Per-object activity trails
Separate from the system-wide log, every major record keeps its own activity trail: creations, field updates, notes, exports, and submissions against that specific object, each attributed to the acting user (or **System** for automated changes).
* **In the dashboard**: shown on the record's activity feed (for example, a vendor's or assessment's activity tab).
* **Through the API**: `GET /v1/activity` with `target_type` and `target_id` query parameters returns the trail for one object; `related_activity=true` pulls in activity from related records (for example, an assessment's findings).
* **Through AI assistants**: the Coverbase [MCP server](/mcp/overview) exposes the trail via `query_platform` with `kind: "audit_trail"` for vendors, assessments, assessment reviews, contracts, findings, services, obligations, follow-ups, portals, vendor documents, work queue items, and evals. The built-in `who_changed_this` prompt scripts a full audit investigation for one object.
## Public-API audit records
Each authenticated public-API request is recorded in your organization's activity log as `type=external_api_call` with `target_type=external_api_request`. Every record captures:
* the HTTP method, request path, and matched route template
* the response status code and duration in milliseconds
* the names of the query parameters used (values are **not** recorded)
* the `ak_*` key ID and human-readable name that authenticated the request
* the client IP and a per-request correlation ID
Audit records are written after the response is sent, so auditing never delays or fails your API calls.
<Note>
Request and response **bodies are never persisted** in the audit log, only metadata about the call. This keeps the trail useful for forensics without itself becoming a sensitive data store.
</Note>
## AI assistant (MCP) activity
AI assistant activity is covered at two layers:
* **Changes made through MCP appear in the audit surfaces.** MCP tool calls run as the connected user, so writes land in the same per-object activity trails (and, for configuration surfaces like controls, custom fields, and Radar detectors, the system-wide audit log), attributed to that user, exactly as if they had made the change in the dashboard. MCP API key creation and revocation appear in the **Integrations** group.
* **Tool invocations are logged server-side.** Every MCP tool call (including reads) is recorded in Coverbase's security logs with the user identity, organization, tool name, sanitized parameters, and outcome, for security monitoring and incident response. Credentials and high-risk PII are redacted before logging. See [MCP security and privacy](/mcp/security) for details.
## Retention
Audit records are retained in line with the retention periods described in our agreements and privacy policy. For long-term retention beyond that window, export the log on a recurring schedule into your own system of record.
## Build a defensible evidence trail
<Steps>
<Step title="Provision a scoped export key">
Have an admin mint an `ak_*` key with the `audit:read` scope for your export job.
</Step>
<Step title="Pull on a schedule">
Poll `GET /v1/system_audit_log` on a fixed cadence with a `start_ts` watermark, paging through results via `limit`/`offset` and the `X-Total-Count` header. See [pagination](/conventions#pagination).
</Step>
<Step title="Ship to your system of record">
Forward records into your SIEM or GRC platform so your auditors see Coverbase activity alongside the rest of your environment.
</Step>
</Steps>
# Compliance and assurance
Source: https://docs.coverbase.com/security/compliance
SOC 2 Type II, independent annual penetration testing, and how to request our reports.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Coverbase backs its security claims with independent assurance. We are examined by an outside SOC 2 auditor and tested by an outside penetration-testing firm, and we make the resulting reports available to customers and prospects under NDA.
## SOC 2 Type II
The Coverbase platform is **SOC 2 Type II** audited. A Type II report covers the *operating effectiveness* of our controls over a continuous observation period, not only their design at a point in time, across the Security (Common Criteria) trust services category.
<CardGroup>
<Card title="Scope" icon="diagram-project">
The audit covers the production Coverbase platform: the application, its data stores, and the cloud infrastructure it runs on. The API and the MCP server inherit the same controls as the core product.
</Card>
<Card title="Cadence" icon="calendar-check">
We maintain continuous coverage, renewing the Type II examination each audit period so there is no gap between reports.
</Card>
<Card title="Independent auditor" icon="user-check">
The examination is performed by an accredited third-party auditing firm, not self-attested.
</Card>
<Card title="Report access" icon="file-shield" href="mailto:security@coverbase.ai">
Request the current report under NDA from [security@coverbase.ai](mailto:security@coverbase.ai).
</Card>
</CardGroup>
## Penetration testing
Coverbase engages an independent, top boutique penetration-testing firm (a team of dedicated security researchers) to test the platform **at least annually**, as well as after significant architectural changes.
* **Independent and external.** Testing is performed by an outside firm whose business is offensive security research, not by the engineers who built the feature.
* **Scope.** Engagements cover the web application, the public API, authentication and authorization, and tenant-isolation boundaries.
* **Remediation.** Findings are triaged by severity, tracked to closure, and verified by retest. Material findings are remediated on a priority timeline appropriate to their severity.
* **Evidence.** A summary letter or attestation of the most recent engagement is available to customers under NDA.
<Note>
We share a penetration-test **summary letter or attestation** rather than the raw report, which can contain sensitive technical detail. The summary confirms scope, methodology, the testing firm, and that findings were remediated.
</Note>
## Continuous control monitoring
Point-in-time audits are necessary but not sufficient. Between formal examinations we continuously monitor the controls that underpin our compliance posture (access reviews, infrastructure configuration, vulnerability status, and change management), so drift is caught and corrected rather than discovered at the next audit.
## Vulnerability disclosure
We welcome reports from the security community and from customers.
<Card title="Report a vulnerability" icon="bug" href="mailto:security@coverbase.ai">
Email [security@coverbase.ai](mailto:security@coverbase.ai). We acknowledge reports within one business day and follow responsible-disclosure timelines. Do not test against other tenants' data or perform denial-of-service testing.
</Card>
## Requesting documentation
<Steps>
<Step title="Email the security team">
Send your request to [security@coverbase.ai](mailto:security@coverbase.ai), naming the documents you need (SOC 2 report, penetration-test attestation, completed security questionnaire).
</Step>
<Step title="Execute an NDA">
Reports are shared under a mutual NDA. If one is already in place between our organizations, reference it.
</Step>
<Step title="Receive the package">
We provide the current report set and can complete standard security questionnaires (for example CAIQ / SIG) on request.
</Step>
</Steps>
# Contract terms and exit
Source: https://docs.coverbase.com/security/contract-terms
The commercial and contractual questions a regulated buyer asks: incident and breach notification, data return and destruction on exit, retention, renewal and notice, subprocessors, and the diligence package Coverbase provides.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Third-party risk teams are asked to diligence Coverbase the way they diligence everyone else. This page answers the contractual questions that normally arrive as a redline, so you can get through them before the negotiation rather than during it.
<Note>
Your executed agreement governs. This page describes the standard Coverbase positions and the operational reality behind them; it is not the contract, and enterprise terms are negotiated.
</Note>
## Incident and breach notification
Coverbase maintains a documented incident-response plan with defined severity levels, named roles and a timed escalation path. See [Security governance](/security/governance#incident-response) for the process and [Support, service levels and escalation](/security/support-and-slas) for the response and update clocks.
On notification specifically:
* **We notify affected customers of incidents affecting their data**, in line with our contractual and regulatory obligations, through the named contacts on your account.
* **Notification windows are contractual and we negotiate on them.** Coverbase contracts with supervised financial institutions, and we are used to notification clauses drawn to a specific regulatory window rather than to a vague "without undue delay". If your institution must notify its primary federal regulator within **36 hours** of determining that a notification incident has occurred (12 CFR 53, 12 CFR 225 subpart N, or 12 CFR 304 subpart C, depending on your supervisor), your service-provider notification clause needs to leave you time to make that call. Bring the language you need; take it to your Coverbase account team and legal contact early, and it is a negotiation rather than a surprise.
* **What we commit to operationally.** Security and platform monitoring surface anomalous activity for triage; on-call responders contain and remediate by severity; customer-affecting events are published to [status.coverbase.com](https://status.coverbase.com) once impact is confirmed, without waiting for the incident to be formally classified; and every material incident is followed by a post-incident review, with a root-cause analysis provided for a P0.
* **Report an incident to us** at [security@coverbase.ai](mailto:security@coverbase.ai). We acknowledge within one business day.
## Data return and destruction on exit
<CardGroup>
<Card title="Get your data out, any time" icon="arrow-up-from-bracket">
Nothing about exit depends on Coverbase's cooperation. Throughout the engagement you can pull vendor, assessment, evaluation, control, finding, obligation and contract data through the [Export API](/export-api-concepts), download every document in bulk as an archive, and generate a complete [due-diligence file](/reporting/due-diligence-file) per third party.
</Card>
<Card title="Deletion on termination" icon="trash">
On termination, customer data is deleted in line with the agreed terms. Deletion cascades to dependent artifacts rather than leaving orphans, and extends to personal data held at a screening provider on your instruction. Deleted data ages out of backups on the backup-retention schedule.
</Card>
<Card title="Certification of destruction" icon="file-shield">
Written confirmation of deletion is available on request at the end of an engagement. Ask your account team, or [security@coverbase.ai](mailto:security@coverbase.ai).
</Card>
<Card title="Export is not a paid service" icon="unlock">
Export is a standard product capability available to any admin, not a paid professional-services engagement and not something that has to be requested. That is deliberate: a system of record that is hard to leave is a concentration risk in its own right.
</Card>
</CardGroup>
<Tip>
Run your exit test before you need it. Pull a full export and a due-diligence package for one vendor during your evaluation, and you will know exactly what an exit looks like rather than taking anyone's word for it, ours included.
</Tip>
## Term, renewal and notice
Subscription term, renewal mechanics and notice periods are set in your order form. Coverbase's standard position is a stated term with a defined notice period rather than an automatic renewal that turns over silently, and we are comfortable with clauses requiring advance written notice of renewal and of any price change.
Two practical notes:
* **We use our own product on our own paper.** Coverbase tracks contract dates, notice windows and renewal deadlines as first-class obligations, which is exactly the capability that stops a renewal from surprising anyone. Load your Coverbase agreement into your own tenant and it reminds you before your notice window closes.
* **Ask early.** Term, renewal, notice, liability, indemnity and incident notification are the six clauses that take longest to settle. Raise them with your account team at the start of an evaluation rather than at signature.
## Subprocessors
Subprocessors that process customer data are assessed for security and privacy posture before they touch customer data, and reassessed on a recurring basis. We use Coverbase to do it. A current subprocessor list is available on request, and material changes are communicated in line with your agreement.
## Diligence package
Everything a third-party risk team normally asks for, available to customers and prospects under a mutual NDA from [security@coverbase.ai](mailto:security@coverbase.ai):
| Document | Notes |
| - | - |
| SOC 2 Type II report | Current report, covering the operating effectiveness of controls across the observation period |
| Penetration test attestation | Summary letter confirming scope, methodology, the testing firm, and remediation, in place of the raw report |
| Completed security questionnaire | We complete standard questionnaires, including CAIQ and SIG |
| Subprocessor list | Current list of subprocessors that process customer data |
| Insurance certificates | On request |
| Business continuity and disaster recovery summary | Recovery objectives and testing approach; see [Security governance](/security/governance#business-continuity-and-disaster-recovery) |
| SLA exhibit | The uptime commitment and severity clocks described in [Support, service levels and escalation](/security/support-and-slas) |
## Related
<CardGroup>
<Card title="Support, service levels and escalation" icon="headset" href="/security/support-and-slas">
Severity ladder, response clocks, escalation path and the uptime commitment.
</Card>
<Card title="Regulatory alignment" icon="landmark" href="/security/regulatory-alignment">
How Coverbase maps to the guidance your examiner cites.
</Card>
<Card title="Data protection" icon="lock" href="/security/data-protection">
Encryption, residency, retention and deletion in technical detail.
</Card>
<Card title="Working with Coverbase" icon="handshake" href="/security/working-with-coverbase">
Company profile, roadmap transparency and how customers shape what gets built.
</Card>
</CardGroup>
# Data protection
Source: https://docs.coverbase.com/security/data-protection
Encryption in transit and at rest, field-level encryption and role-based masking of sensitive identifiers, tenant isolation, key management and rotation, data residency, retention and deletion.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Your vendor data, assessment evidence, contracts and supplier identifiers are protected in transit and at rest, isolated to your organization, masked from anyone who does not need to see them in full, and held only as long as you need them.
## Encryption
<CardGroup>
<Card title="In transit" icon="lock">
All connections use TLS 1.2 or higher, with certificates from recognized authorities. There is no unencrypted surface: the API, the dashboard, the vendor portal and the MCP server are HTTPS only.
</Card>
<Card title="At rest" icon="database">
Customer data is encrypted at rest with AES-256 across every store: the transactional database, object storage, search indexes, block storage and backups. Encryption is enforced at the infrastructure level rather than left to the application.
</Card>
</CardGroup>
### Field-level encryption
Some data is worth stealing on its own, so it is not stored in a readable column even inside an already-encrypted database. Supplier **bank account identifiers** and **tax registration numbers** are sealed individually with **AES-256-GCM**, under a dedicated key held separately from the database.
* **Authenticated encryption.** Each value set is sealed as a single envelope carrying its own nonce, so a ciphertext cannot be tampered with undetected or replayed onto another record.
* **Versioned keys, rotatable without a migration.** Every envelope records the key version it was sealed under, so the key can be rotated while previously sealed rows keep opening under the version that wrote them.
* **One decryption path.** Exactly one module can open an envelope, and it is reached only by a caller holding the elevated banking scope or by a validation path that genuinely needs the raw value. Nothing else in the platform can decrypt.
* **Blind matching.** "Is this the same account we already hold?" and "did this account change?" are answered with a one-way HMAC fingerprint over the normalized identifiers, so change detection never decrypts anything and a fingerprint reveals nothing about the value behind it.
### Role-based masking
Encryption protects the stored value. Masking is what governs whether anyone sees it, on screen, in an export, or in a webhook payload.
A sensitive identifier is represented by its **last four characters and nothing else** everywhere except an explicitly scoped read. That rule is enforced in one place that every consumer passes through, so adding a new report, integration or event cannot quietly add a new leak.
| Surface | What it shows |
| - | - |
| Dashboard, without the banking scope | Masked to last four |
| API response, without the banking scope | Masked to last four |
| Change-event diffs and webhook payloads | Masked to last four, on both the old and new value |
| Notifications and emails | Masked to last four |
| Logs | Never carry the value at all |
| API read carrying the elevated banking scope | Full value, and the read is recorded |
Institution-identifying fields that a reviewer needs to sanity-check a change, such as the bank name, SWIFT/BIC, bank code and branch code, stay readable. The account identifier does not. A reviewer can therefore approve or reject a bank-detail change on the evidence that matters without ever being shown the account number.
<Note>
Separation of duties is enforced on the same data. A service account, which is what every API key authenticates as, can **request** a change to supplier bank details, and by default cannot **approve** one: approval stays with a person. Bypassing that queue requires a separate, admin-minted, revocable scope that no key carries unless an admin deliberately grants it. See [API key scopes](/conventions#api-key-scopes).
</Note>
### Beneficial-owner and officer data
Personal data about a third party's officers and ultimate beneficial owners is handled as a distinct, higher-sensitivity class rather than as ordinary vendor data.
* **Off by default.** Officer and beneficial-owner screening is not enabled unless your organization deliberately turns it on, because screening a person means holding watchlist assertions about a named private individual.
* **Sourced, not guessed.** Only people named in a corporate registry filing are eligible as subjects, and only where their link to the vendor was accepted rather than merely plausible.
* **Its own permission.** Screening results are a separate access-control resource with its own read, update and export permissions, so a compliance reviewer can be given the screening queue without vendor edit rights, and a vendor owner can hold the vendor without the ability to close a sanctions match. There is no human create or delete; matches are written by the pipeline.
* **Classified and cascading.** Identity attributes sent to a screening provider are classified as personal data, and every artifact cascades on subject deletion, so retiring a subject is a delete rather than an orphaned row.
* **Erasure reaches the provider.** A monitored profile is personal data held at a provider on Coverbase's instruction. Deleting a vendor, merging one away, or dropping it out of monitoring queues the profile's retirement at the provider too, and an unreachable provider delays that rather than dropping it.
## Tenant isolation
Coverbase is multi-tenant, and isolation between tenants is enforced in depth rather than at a single boundary.
* **Every record is org-scoped.** Each object carries the ID of its owning organization, and that scope is enforced at the data-access layer on every read and write, not only at the API edge.
* **Credentials are single-org.** An API key authenticates to exactly one organization; everything it reads or writes is implicitly scoped to that org. A request can never reach another tenant's data by changing an ID. See [API conventions](/conventions#authentication).
* **AI access inherits the boundary.** MCP tool calls run with the connected user's permissions and cannot escalate beyond what that user could do in the UI. See [MCP permissions](/mcp/permissions).
* **Your documents are never pooled.** The one deliberately shared dataset, the [document library](/products/document-library), is built exclusively from documentation Coverbase collects itself. Documents your organization uploads, and documents vendors send you through an assessment portal, are never added to it.
<Note>
A resource ID that does not belong to your organization is treated as not found (`404`), the same response as an ID that does not exist, so existence in another tenant is never leaked.
</Note>
## Key and secret management
<CardGroup>
<Card title="Managed keys with automatic rotation" icon="key">
Encryption keys are AWS KMS customer master keys held in Coverbase's account, with **automatic key rotation enabled**. Keys are separated by purpose rather than shared: distinct keys for the database, object storage, search, block storage, the secrets store, and individual integration credential stores.
</Card>
<Card title="Secrets never live in the database" icon="vault">
Application secrets and per-organization integration credentials are stored in a managed secrets service (AWS Secrets Manager), one secret per credential rather than one shared document, under a key prefix scoped to the owning organization. The database holds a pointer and metadata; the value is never in a column, in source control, or in a config file. No route ever returns a stored credential.
</Card>
</CardGroup>
<Info>
**Customer-managed keys.** Coverbase does not currently offer bring-your-own-key against a KMS key in your own AWS account. Encryption keys are Coverbase-managed KMS CMKs, separated by purpose and rotated automatically, as described above. If a customer-managed key is a control requirement for your program, raise it with your Coverbase team at [security@coverbase.ai](mailto:security@coverbase.ai) so it is scoped rather than assumed.
</Info>
How integration credentials, OAuth client secrets, customer S3 roles and webhook signatures are handled is described in [Integration credentials and signing](/security/integration-credentials).
## Network controls
Organizations can lock down where API access is allowed to originate from.
<Card title="API IP allowlist" icon="network-wired" href="/conventions#api-ip-allowlist">
Restrict all public-API (`ak_...` key) requests to a set of IPv4/IPv6 CIDRs. The control is fail-closed and uses the unspoofable load-balancer-provided client IP. See [API IP allowlist](/conventions#api-ip-allowlist).
</Card>
## Data residency
The multi-tenant Coverbase production environment runs on AWS in the **United States** (`us-east-1`), across multiple availability zones. Customer data, backups and search indexes stay within that region. AI model inference is processed through AWS Bedrock's cross-region inference, which can serve a request from another AWS region; see [AI governance](/security/ai-governance#model-selection-and-hosting).
The entire platform is defined as infrastructure-as-code and parameterized by region, so a deployment in another AWS region, including the EU, is a configuration of the same stack rather than a rebuild. Programs with a specific residency obligation should raise it during evaluation: contact [security@coverbase.ai](mailto:security@coverbase.ai) and we will tell you what is available on what timeline rather than leaving it open.
Subprocessors that process customer data are assessed before onboarding and reviewed on a recurring basis, and the current list is available on request. See [Security governance](/security/governance#vendor-and-subprocessor-management).
## Retention and deletion
* **Retention.** We retain customer data for the life of your subscription and the period defined in your agreement and our privacy policy.
* **Deletion.** On contract termination, customer data is deleted in line with the agreed terms. You can also delete or archive records yourself through the dashboard and API throughout the engagement, and deletion cascades to the dependent artifacts rather than orphaning them.
* **Backups.** Deleted data ages out of backups according to the backup-retention schedule.
* **Export before exit.** Everything is retrievable before you leave, through the [Export API](/export-api-concepts), bulk document download, and per-assessment [evidence packages](/reporting/due-diligence-file). See [Contract terms and exit](/security/contract-terms).
<Card title="Privacy policy" icon="user-shield" href="https://www.coverbase.com/privacy-policy">
See the Coverbase Privacy Policy for how we handle personal data, including data-subject requests.
</Card>
# Security governance
Source: https://docs.coverbase.com/security/governance
Policies, ownership, access control, personnel security, vendor management, and incident response.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Security at Coverbase is governed, not improvised. We maintain a documented control program with named ownership, periodic review, and the same risk-management discipline we help our customers apply to their own third parties.
## Governance program
<CardGroup>
<Card title="Documented policies" icon="file-lines">
A maintained set of information-security policies (access control, data classification, secure development, incident response, business continuity, and acceptable use), reviewed at least annually.
</Card>
<Card title="Named ownership" icon="user-tie">
Security is owned by leadership, not left ambient. Each control area has an accountable owner responsible for its operation and review.
</Card>
<Card title="Risk management" icon="scale-balanced">
We run a recurring risk-assessment process to identify, rate, and treat risks to the platform and to customer data, with treatment tracked to closure.
</Card>
<Card title="Policy review" icon="arrows-rotate">
Policies and the controls behind them are reviewed on a fixed cadence and after material changes to the product or infrastructure.
</Card>
</CardGroup>
## Access control
We operate on least privilege and need-to-know.
* **Role-based access.** Access to systems and to customer data is granted by role, scoped to what the role requires, and reviewed periodically.
* **Strong authentication.** Workforce access to internal systems requires SSO with multi-factor authentication. Customer access to the dashboard is authenticated through our identity provider (Clerk).
* **Production access is gated.** Access to production systems is restricted to authorized personnel, granted on need, and logged.
* **Joiner / mover / leaver.** Access is provisioned on role and revoked promptly on role change or departure.
* **Scoped API credentials.** API keys default to no elevated scopes; admins grant the minimum scope required, and a scoped key can never escalate its own access. See [API key scopes](/conventions#api-key-scopes).
## Personnel security
* **Background checks** are conducted on personnel where permitted by law.
* **Security awareness training** is delivered at onboarding and refreshed periodically.
* **Confidentiality obligations** apply to all personnel with access to customer data.
## Vendor and subprocessor management
We assess our own vendors and subprocessors before onboarding and on a recurring basis, and we use Coverbase to do it.
* Subprocessors are vetted for security and privacy posture before they touch customer data.
* A current list of subprocessors is available on request, and material changes are communicated in line with our agreements.
## Business continuity and disaster recovery
<CardGroup>
<Card title="Resilient infrastructure" icon="server">
The platform runs on managed cloud infrastructure across multiple availability zones to tolerate component failure.
</Card>
<Card title="Backups" icon="database">
Customer data is backed up regularly. Restoration is tested so backups are known to be recoverable, not merely present.
</Card>
<Card title="Recovery objectives" icon="clock-rotate-left">
We maintain defined recovery objectives (RTO/RPO) and a documented plan to restore service after disruption.
</Card>
<Card title="Tested plan" icon="clipboard-check">
The continuity and recovery plan is exercised and updated, not left on a shelf.
</Card>
</CardGroup>
## Incident response
We maintain a documented incident-response plan with defined roles, severity levels, and escalation paths.
<Steps>
<Step title="Detect">
Security and platform monitoring surface anomalous activity for triage.
</Step>
<Step title="Respond and contain">
On-call responders triage, contain, and remediate according to severity.
</Step>
<Step title="Notify">
Where an incident affects customer data, we notify affected customers in line with our contractual and regulatory obligations.
</Step>
<Step title="Learn">
Each material incident is followed by a post-incident review that feeds corrective actions back into the program.
</Step>
</Steps>
<Info>
Suspect a security incident involving Coverbase? Contact [security@coverbase.ai](mailto:security@coverbase.ai) immediately.
</Info>
# Identity and access management
Source: https://docs.coverbase.com/security/identity-and-access
How people sign in to Coverbase and how their access ends: SAML 2.0 single sign-on with your identity provider's MFA and conditional access, just-in-time provisioning, IGA-driven lifecycle management, role-based access control, and network restriction.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Coverbase does not want to be your identity provider. Authentication is delegated to the IdP your organization already governs, so the access policy you have already written, and already prove to your auditors, is the policy that applies to Coverbase.
## Single sign-on
<CardGroup>
<Card title="SAML 2.0" icon="key">
Enterprise SSO over SAML 2.0, configured per organization against a verified email domain. Both **SP-initiated** and **IdP-initiated** sign-in are supported, and IdP-initiated can be switched off if your policy requires SP-initiated only.
</Card>
<Card title="Self-serve setup" icon="sliders">
An admin sets it up from **Configuration → Organization → Single Sign-On**: copy the ACS URL and SP entity ID into your IdP, paste your IdP metadata URL back, test the connection, activate. No support ticket, no professional services.
</Card>
<Card title="Just-in-time provisioning" icon="user-plus">
A user who signs in through your IdP for the first time gets a Coverbase account created from the assertion. Email, first name and last name stay synchronized from the IdP on subsequent sign-ins.
</Card>
<Card title="No password to steal" icon="shield-halved">
An SSO user has no Coverbase password. Coverbase never sees a credential, so credential policy, rotation and recovery stay entirely inside your IdP.
</Card>
</CardGroup>
Coverbase runs the self-serve wizard against **Okta** today. Other SAML 2.0 identity providers, including **Microsoft Entra ID**, **Google Workspace**, **Ping** and **OneLogin**, are supported through the same connection model and are set up with your Coverbase team. Ask us before you plan around it, and we will confirm your provider on the call rather than after the contract.
### MFA and conditional access
Because authentication happens at your IdP, your authentication policy is enforced **before** an assertion ever reaches Coverbase:
* **Multi-factor authentication** is enforced by your IdP's policy. Coverbase accepts the assertion your IdP produces; it has no way to bypass the factor your policy demanded.
* **Microsoft Entra Conditional Access**, Okta's sign-on policies, and their equivalents apply to Coverbase as they apply to any other SAML application: device compliance, managed-device requirements, network location, risk-based step-up, session lifetime and re-authentication frequency all carry through.
* **Application assignment** in your IdP is the outer gate. Removing the Coverbase app assignment stops sign-in immediately, regardless of what Coverbase itself still holds.
<Note>
Coverbase deliberately has no MFA setting of its own. A separate factor policy inside a SaaS application is a second policy to keep aligned with the one your IdP already enforces, and a second place for the two to disagree.
</Note>
## Lifecycle management
Provisioning, role change and deprovisioning are exposed as an API designed for identity-governance tooling to drive.
| Operation | Endpoint | Behavior |
| - | - | - |
| Provision | `POST /v1/users` | Create-or-get. Creates the account and an org membership in `invited` status, idempotent under an `Idempotency-Key`. The user links to your IdP by email on first SSO. |
| Look up | `GET /v1/users?email=` | Resolve an email to a Coverbase user ID, for downstream owner and reviewer assignment. |
| Change role | `PATCH /v1/users/{id}` | Move a user between Admin, Member, Siloed member, Auxiliary member and Guest. |
| Deprovision | `PATCH /v1/users/{id}` | Archives the user and sets org membership to `inactive`. Reversible by the same call, so a leaver who returns is reactivated rather than duplicated. |
This is the integration point SailPoint, Okta Workflows, Microsoft Entra lifecycle workflows and HRIS-driven joiner/mover/leaver pipelines target: your IGA platform owns the approval, and Coverbase reflects the resulting entitlement.
<Info>
**SCIM.** Coverbase does not publish a SCIM 2.0 service-provider endpoint today. Lifecycle is driven through the Users API above, which every major IGA platform can call from an outbound connector or workflow, and which is what our identity-governance customers use. If a native SCIM endpoint is a requirement for your program, raise it with your Coverbase team so it can be planned rather than assumed.
</Info>
Removing someone's IdP assignment blocks sign-in immediately. Deprovisioning through the API also removes their access to org data and takes them out of assignment and notification routing. Do both; they answer different questions in an access review.
## Authorization inside Coverbase
Once someone is authenticated, what they can reach is governed by role-based access control.
* **Six default roles** (Admin, Member, Siloed member, Auxiliary member, Guest, Service account) plus **custom roles** built from a resource, an action and a scope.
* **Record-level scoping.** A Siloed member sees the same features against only the records they own, watch or analyze.
* **Least privilege by default.** API keys carry no elevated scopes unless an admin grants them, and a scoped key can never grant a scope, not to itself and not to another key.
* **Separation of duties.** Service accounts, which is what every API key authenticates as, can request a change to supplier bank details but by default cannot approve one; approval stays with a person. Bypassing that review requires a separate scope an admin has to mint deliberately and can revoke. See [API key scopes](/conventions#api-key-scopes).
Full detail: [Permissions and roles](/user-guides/permissions-and-roles).
## Session and network controls
<CardGroup>
<Card title="API IP allowlist" icon="network-wired" href="/conventions#api-ip-allowlist">
Restrict every public-API request to a set of IPv4/IPv6 CIDRs. The control is fail-closed and evaluates the load-balancer-provided client IP, which a caller cannot spoof.
</Card>
<Card title="Session policy at the IdP" icon="clock-rotate-left">
Session lifetime, idle timeout and re-authentication frequency follow your IdP's session policy for SSO users.
</Card>
<Card title="Scoped, rotatable API keys" icon="key" href="/api-reference/api-keys">
Admins list, create, rotate and revoke keys self-service. Each key is bound to exactly one organization.
</Card>
<Card title="Short-lived OAuth tokens" icon="clock" href="/security/integration-credentials#oauth-client-secrets">
Integrations that cannot hold a long-lived key can use OAuth 2.0 client credentials: the secret is shown once and stored hashed, and tokens last at most an hour.
</Card>
<Card title="Every call is logged" icon="list-timeline" href="/conventions#public-api-audit-log">
Every authenticated public-API request records the method, route, status, duration, key ID and name, client IP and a correlation ID. Bodies are never persisted.
</Card>
</CardGroup>
## Access reviews
Everything an access review asks for is readable without a support request:
* Current members, their roles and their membership status, from the dashboard or `GET /v1/users`.
* What each role can do, from the permission matrix, exportable per role.
* Who changed a role, and when, from the role's own activity log and the organization [audit trail](/security/audit-trails).
* Which API keys exist, who minted them, what scopes they hold, and what each has called.
## Related
<CardGroup>
<Card title="Permissions and roles" icon="lock-keyhole" href="/user-guides/permissions-and-roles">
The six default roles and how custom roles are built.
</Card>
<Card title="Security governance" icon="sitemap" href="/security/governance">
How Coverbase governs its own workforce access.
</Card>
<Card title="Data protection" icon="lock" href="/security/data-protection">
Encryption, field-level protection, tenant isolation and residency.
</Card>
<Card title="Audit trails" icon="list-timeline" href="/security/audit-trails">
The exportable record of every action.
</Card>
</CardGroup>
# Integration credentials and signing
Source: https://docs.coverbase.com/security/integration-credentials
How Coverbase protects the credentials integrations use and proves who is calling: OAuth client secrets shown once and stored hashed, write-only connector and warehouse credentials, customer S3 roles assumed with a per-destination external ID, and HMAC-signed webhooks in both directions.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Integrations are where credentials leave a person's hands and sit in a system. This page describes how Coverbase keeps the credentials you give it, the ones it gives you, and how each side of a webhook proves who sent it. For encryption, tenant isolation and key management generally, see [Data protection](/security/data-protection).
## Principles
* **A secret is shown once, or never.** Secrets Coverbase generates for you are displayed at creation and cannot be read back. Secrets you give Coverbase are write-only: no page or API response returns them.
* **Credentials live in a secrets manager, not the database.** The database keeps a pointer and non-secret metadata, such as which fields are set, a key fingerprint or a service account email.
* **A credential is scoped to its owner.** Each is stored under its organization and its connection or destination, and deleting the connection or destination deletes the credential.
* **A body is never trusted on its own.** Webhooks in both directions are signed with HMAC-SHA256 over the raw bytes, and inbound webhooks only start a sync that re-reads the data from its source.
## OAuth client secrets
Organizations with the third-party lifecycle features can create [OAuth 2.0 clients](/api-reference/oauth) for the public API.
* **Shown once.** The client secret is displayed when the client is created and never again. Coverbase stores only its SHA-256 digest and its last four characters, so a client can be told apart without the secret being readable.
* **High-entropy and hashed.** Client secrets and access tokens are random 256-bit values, stored only as SHA-256 digests. The token endpoint compares digests in constant time, and does the comparison even for an unknown client ID, so response timing does not reveal which client IDs exist. A token request must use one client authentication method, HTTP Basic or form fields, not both.
* **Short-lived tokens.** An access token lasts between five minutes and an hour, set per client, and the token response carries `Cache-Control: no-store`.
* **Capped per client.** A client holds at most 50 live tokens. Requesting another revokes its oldest, so a leaked secret looping on the token endpoint cannot pile up grants.
* **No escalation.** Only an admin signed in to the dashboard can grant elevated scopes to a client, as with `ak_*` keys. A token request can only narrow the client's scopes.
* **Immediate revocation.** Revoking a client deletes every token it issued, and a client stops getting tokens if the third-party lifecycle features are turned off for your organization. A server that cached a token's identity can keep accepting it for a few seconds.
* **Audited.** Creating and revoking clients is recorded in the activity log, and every call made with a token is recorded in the [public API audit log](/conventions#public-api-audit-log), like a call made with a key.
## Connector credentials
Credentials for [Integration Hub](/products/integration-hub) connectors (Coupa, SAP Ariba, Ironclad, Icertis, Microsoft Teams) and for licensed connectors (Bitsight, SecurityScorecard, RapidRatings, Moody's, ISNetworld, Avetta, EcoVadis) are stored in AWS Secrets Manager under the organization, and for an Integration Hub connector under the connection too. Pages show only which fields are set and non-secret identifiers. A Microsoft Teams webhook URL is itself a credential, since anyone who holds it can post to the channel, so only its host is ever shown, and only Teams webhook hosts are accepted.
When a connector's sync fails, the status Coverbase records is its own error message, never a credential or the provider's response body.
## Warehouse destination credentials
A [warehouse data share](/products/warehouse-data-share) credential is written to Secrets Manager under the organization and the destination the moment it is submitted. The destination keeps a pointer and a non-secret hint: the key's public fingerprint for Snowflake, the service account email for BigQuery. No response returns the credential or its pointer. Archiving the destination deletes the secret.
## Customer S3 roles and external IDs
An Amazon S3 destination stores no secret at all. Coverbase writes to your bucket by assuming an IAM role in your account.
* **A per-destination external ID.** When you save the destination, Coverbase generates an external ID for it, starting with `coverbase-`, and shows it on the destination with a ready-made trust policy. Your role's trust policy requires that external ID, so the role cannot be assumed for any other customer's destination, even if someone learns its ARN. This is the protection AWS recommends against the confused deputy problem.
* **One named principal.** The trust policy names a single, dedicated Coverbase role whose only job is assuming customer share roles. Coverbase's services reach your role only through it, and its ARN stays the same if those services are redeployed.
* **Coverbase's side is constrained too.** That role is permitted to assume a role only when the request carries a `coverbase-` external ID and the role is outside Coverbase's own AWS account, and a destination naming a role in Coverbase's account is refused when it is saved.
* **Least privilege.** The role needs only `s3:PutObject` under the prefix you choose. You can remove the trust at any time to cut access.
## Outbound webhooks
Coverbase signs every [webhook](/integrations/webhooks) it sends with HMAC-SHA256 over the raw request body, keyed by the secret you set on the endpoint, in the `Coverbase-Signature` header. Verify it against the raw bytes with a constant-time comparison before acting on the payload. You set the secret, and Coverbase never shows it again after you save. See [Signature verification](/integrations/webhooks#signature-verification).
## Inbound integration webhooks
A procurement or contract system can call Coverbase to ask for an immediate sync of a changed record. These calls carry no bearer token, so Coverbase authenticates them by signature alone:
* **Signed with a per-connection secret.** The `X-Coverbase-Signature` header has the form `t=<unix seconds>,v1=<hex>`, where the digest is HMAC-SHA256 of `<t>.` followed by the raw body, keyed by the connection's signing secret. The secret is shown once, when it is created or rotated.
* **Replay-resistant.** The timestamp is inside the signature and must be within five minutes of Coverbase's clock.
* **Verified before anything happens.** Coverbase verifies the signature before it reads the payload or does anything else. A missing or wrong signature returns `401`, and a body over 256 KB is refused.
* **A nudge, not data.** A valid call only starts a sync, and the sync re-reads every record from the provider's API with Coverbase's stored credentials. Even a correctly signed body cannot write a value into Coverbase.
## Related
<CardGroup>
<Card title="Data protection" icon="lock" href="/security/data-protection">
Encryption, key management and tenant isolation.
</Card>
<Card title="Identity and access" icon="id-badge" href="/security/identity-and-access">
Sign-in, roles and API keys.
</Card>
<Card title="AI governance" icon="brain-circuit" href="/security/ai-governance">
Redaction before model calls and the Agent Ledger.
</Card>
<Card title="OAuth API" icon="code" href="/api-reference/oauth">
The token endpoint and client management.
</Card>
</CardGroup>
# Trust and security overview
Source: https://docs.coverbase.com/security/overview
How Coverbase governs, secures, and makes auditable the third-party risk platform you run your program on.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Coverbase is the system of record for your third-party risk program. We hold vendor data, assessment evidence, contracts, and findings, the same material your auditors and regulators ask about. We hold ourselves to the standard we help you hold your own vendors to.
This section documents how we govern the platform, how we secure it, and how we make every action on it auditable. It is written for the security, compliance, and procurement teams who evaluate Coverbase as a vendor.
## Our security model
Our program is built on the same principles top security organizations operate by: independent assurance, defense in depth, least privilege, and verifiable auditability. Nothing here is aspirational: each pillar maps to a control that is in place today and is exercised in our SOC 2 Type II audit.
<CardGroup>
<Card title="Compliance and assurance" icon="certificate" href="/security/compliance">
SOC 2 Type II, independent annual penetration testing, and continuous control monitoring. Request our reports under NDA.
</Card>
<Card title="Security governance" icon="sitemap" href="/security/governance">
Documented policies, named ownership, role-based access, personnel security, and a tested incident-response and business-continuity program.
</Card>
<Card title="Data protection" icon="lock" href="/security/data-protection">
Encryption in transit and at rest, field-level encryption and role-based masking of sensitive identifiers, tenant isolation, key management and rotation, residency, retention and deletion.
</Card>
<Card title="Identity and access management" icon="id-badge" href="/security/identity-and-access">
SAML 2.0 single sign-on inheriting your identity provider's MFA and conditional access, just-in-time provisioning, IGA-driven lifecycle, RBAC, and network restriction.
</Card>
<Card title="Secure development" icon="code-branch" href="/security/secure-development">
A secure SDLC with mandatory review, automated type/lint/test gates, dependency and secret scanning, and least-privilege CI/CD.
</Card>
<Card title="AI governance" icon="brain-circuit" href="/security/ai-governance">
How we select, test, and constrain the AI models that power Coverbase, including evaluation, human oversight, and customer-data handling.
</Card>
<Card title="Audit trails" icon="list-timeline" href="/security/audit-trails">
Every action in the dashboard, over the API, and through AI assistants is logged and exportable through the audit API.
</Card>
</CardGroup>
## Buying Coverbase
The questions a third-party risk team asks about us, answered before you have to ask them.
<CardGroup>
<Card title="Regulatory alignment" icon="landmark" href="/security/regulatory-alignment">
How the platform maps to the 2023 Interagency Guidance on Third-Party Relationships, the Interagency Guidelines Establishing Information Security Standards, FFIEC, GLBA, DORA and NCUA expectations.
</Card>
<Card title="Support, service levels and escalation" icon="headset" href="/security/support-and-slas">
The P0 to P3 severity ladder with response and update commitments, the timed on-call escalation path, the 99.9% uptime commitment and how it is measured.
</Card>
<Card title="Contract terms and exit" icon="file-contract" href="/security/contract-terms">
Incident and breach notification, data return and destruction on exit, renewal and notice, subprocessors, and the diligence package we provide under NDA.
</Card>
<Card title="Working with Coverbase" icon="handshake" href="/security/working-with-coverbase">
Company and viability diligence, release cadence and roadmap transparency, early access, and how customers influence what gets built.
</Card>
</CardGroup>
## Principles
<AccordionGroup>
<Accordion title="Independent assurance over self-attestation" icon="user-check">
We do not ask you to take our word for it. Our controls are examined annually by an independent SOC 2 auditor and tested by an outside penetration-testing firm. See [Compliance and assurance](/security/compliance).
</Accordion>
<Accordion title="Least privilege everywhere" icon="key">
Access for our people, our systems, and your API credentials defaults to the minimum required. Production access is gated and logged; API keys carry no elevated scopes unless an admin grants them. See [Security governance](/security/governance) and [API conventions](/conventions#api-key-scopes).
</Accordion>
<Accordion title="Tenant isolation by construction" icon="layer-group">
Every record is scoped to its owning organization, and that scope is enforced in depth at the data-access layer, not only at the edge. See [Data protection](/security/data-protection#tenant-isolation).
</Accordion>
<Accordion title="Everything is auditable" icon="magnifying-glass">
Dashboard actions, public-API calls, and AI assistant tool calls all land in the same audit trail, which you can read and export programmatically. See [Audit trails](/security/audit-trails).
</Accordion>
</AccordionGroup>
## Contact
<CardGroup>
<Card title="Security team" icon="shield-halved" href="mailto:security@coverbase.ai">
Reach our security team at [security@coverbase.ai](mailto:security@coverbase.ai) for reports, questionnaires, or documentation requests.
</Card>
<Card title="Request reports" icon="file-shield" href="mailto:security@coverbase.ai">
SOC 2 reports and penetration-test summary letters are available to customers and prospects under NDA.
</Card>
<Card title="Privacy policy" icon="user-shield" href="https://www.coverbase.com/privacy-policy">
See the Coverbase Privacy Policy for how we handle personal data.
</Card>
</CardGroup>
# Regulatory alignment for banks and credit unions
Source: https://docs.coverbase.com/security/regulatory-alignment
How Coverbase maps to the 2023 Interagency Guidance on Third-Party Relationships, the Interagency Guidelines Establishing Information Security Standards (Appendix D-2 to Regulation H), FFIEC outsourcing guidance, GLBA, DORA and NCUA expectations.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Coverbase is built for regulated third-party risk programs, and a large share of its customers are banks, credit unions, and fintechs supervised by the federal banking agencies. This page maps the platform to the guidance those examiners cite, stage by stage.
<Note>
This is an alignment map, not a legal opinion or a certification. Coverbase is a tool your program runs on; the program remains yours, and so does the responsibility. Nothing here transfers a supervisory obligation from your institution to Coverbase.
</Note>
## Interagency Guidance on Third-Party Relationships (2023)
The Board of Governors of the Federal Reserve System, the OCC and the FDIC issued the [Interagency Guidance on Third-Party Relationships: Risk Management](https://www.federalregister.gov/documents/2023/06/09/2023-12340/interagency-guidance-on-third-party-relationships-risk-management) in June 2023, replacing the agencies' separate guidance (including FRB SR 13-19 / 13-21, OCC Bulletin 2013-29, and FDIC FIL-44-2008) with one framework built around the third-party relationship life cycle.
Coverbase ships the guidance as a control set as well as implementing it as a workflow. The [Control Set library](/control-library) carries **Interagency Guidance on Risk Management (Full)** at 156 controls across 12 sections, and a **(Lite)** variant at 44 controls for lower-criticality relationships. Both can be forked into a control set of your own and edited freely.
### The life cycle, stage by stage
<AccordionGroup>
<Accordion title="Planning" icon="clipboard-list">
Coverbase's [intake](/products/autonomous-intake) captures the business case, the data the third party will touch, the business line, the activity, and whether it supports a critical activity, before any diligence starts. An **inherent risk questionnaire** scores the relationship and drives what depth of diligence follows, so the level of effort is risk-based rather than uniform. Concentration and fourth-party exposure are recorded as relationships and visible at planning time.
</Accordion>
<Accordion title="Due diligence and third-party selection" icon="magnifying-glass">
Assessments run against the control sets you select, with evidence collected from the third party, from its own published attestations, and from independent sources.
The guidance's named diligence areas each have a home in the platform: **strategies and goals**, **legal and regulatory compliance**, **financial condition** ([Financial Health Score](/products/financial-health-score) with a confidence tier that says what the number rests on), **business experience**, **qualifications and backgrounds of principals** ([People Intelligence](/products/people-intelligence), [corporate registrations](/products/corporate-registrations), and [sanctions and PEP screening](/user-guides/sanctions-screening) of the entity, its officers and its beneficial owners), **risk management**, **information security** ([Security Intelligence](/products/security-intelligence) and evidence-backed control evaluation), **management of information systems**, **operational resilience**, **incident reporting and management**, **physical security**, **human resource management**, **reliance on subcontractors** (nth-party relationships), **insurance coverage**, and **contractual arrangements** ([Contract Guardian](/products/contract-guardian)).
</Accordion>
<Accordion title="Contract negotiation" icon="file-signature">
Contract Guardian holds your standard as a clause playbook with tiered acceptable language, then reads the third party's paper against it. The guidance's contract provisions map directly onto reference clauses: nature and scope, performance measures and benchmarks, responsibilities for providing and receiving information, the right to audit and to require remediation, responsibility for compliance with applicable law, cost and compensation, ownership and licensing, confidentiality and integrity, operational resilience and business continuity, **indemnification**, insurance, dispute resolution, limits on liability, **default and termination**, **customer complaints**, **subcontracting**, foreign-based third parties, and **regulatory supervision**. Missing provisions are reported as missing, not silently passed.
</Accordion>
<Accordion title="Ongoing monitoring" icon="satellite-dish">
[Supplier Radar](/products/supplier-radar) monitors third parties continuously against breach, sanctions, enforcement, financial-distress, ownership-change and adverse-media signals, and raises a signal against the vendors your organization is exposed to. Scheduled reassessment runs on a cadence you set by tier. Contract dates and notice periods drive their own reminders. Findings and remediation commitments are tracked to closure with evidence, and evidence that goes stale is re-requested rather than assumed to still hold.
</Accordion>
<Accordion title="Termination" icon="door-open">
Offboarding is a lifecycle stage with its own workflow: a termination assessment scoped to data return, access revocation and exit obligations extracted from the contract; a structured offboarding questionnaire covering destruction certification and access termination; document archival with retention metadata; and events fired to your IAM, procurement and finance systems so the internal cleanup happens too. See [End-to-end workflows](/integrations/end-to-end-workflows#workflow-c-vendor-offboarding).
</Accordion>
</AccordionGroup>
### Governance, oversight and accountability
The guidance devotes as much attention to how the board and senior management oversee the program as to the life cycle itself. Coverbase supports that side directly.
| Expectation | Where it lives |
| - | - |
| Independent reviews of the third-party risk management process | Everything is evidenced: the [audit trail](/security/audit-trails) records every action by every actor, and assessments, findings and decisions export in full |
| Documentation and reporting throughout the life cycle | [Evidence packages and due-diligence files](/reporting/due-diligence-file), custom board-ready Word reports, and the [Export API](/export-api-concepts) |
| Board and senior management reporting | [Dashboards and charts](/user-guides/dashboard-library), including criticality, tier, domain-level risk, open findings, overdue commitments and reassessment status |
| Accountability for approvals | [Reviews, approvals and gates](/user-guides/reviews-and-approvals): who decided, what outcome, why, on which round |
| Risk-based level of effort | Conditional workflow routing on inherent risk, criticality, data classification, jurisdiction and contract value |
| Critical activities identified and treated differently | Vendor tier and criticality drive assessment depth, monitoring cadence, approval quorum and reassessment frequency |
## Interagency Guidelines Establishing Information Security Standards
The information security standards issued under sections 501(b) and 505(b) of the Gramm-Leach-Bliley Act appear as **Appendix D-2 to Regulation H** for state member banks (12 CFR part 208), and in the equivalent appendices for the other agencies (12 CFR part 30 appendix B for national banks, 12 CFR part 364 appendix B for state non-member banks). Section III.D of the Guidelines places specific obligations on an institution that uses a service provider.
| Guidelines requirement (§ III.D) | How Coverbase supports it |
| - | - |
| **Exercise appropriate due diligence in selecting service providers** | Risk-based assessment against the control set you choose, with evidence, citations, and a recorded approval decision per third party and per service |
| **Require service providers by contract to implement appropriate measures designed to meet the objectives of the Guidelines** | Contract Guardian clause playbooks, with information-security, confidentiality, breach-notification and audit-rights clauses as reference clauses, and missing-clause detection where they are absent |
| **Where indicated by the risk assessment, monitor service providers to confirm they have satisfied their obligations** | Continuous monitoring, scheduled reassessment, obligation tracking against extracted contract obligations, and evidence-refresh workflows |
| **Review audits, summaries of test results, or other equivalent evaluations** | Automated intake and analysis of SOC 1 / SOC 2 reports, bridge letters, ISO certificates and penetration-test reports, with exceptions and CUECs surfaced rather than buried |
| **Adjust the program in light of relevant changes** | Radar signals, drift detection on re-inspection, and re-evaluation of contracts on amendment |
| **Report to the board** | Program-level dashboards and exportable reporting |
The **GLBA 16 CFR Part 313** control set is in the library at 20 controls (privacy and opt-out notices, limits on disclosures, and exceptions), alongside the banking-agency framing above.
## Other frameworks in the library
| Framework | Controls | Use |
| - | -: | - |
| [FFIEC Contract Requirements](/control-library) | 30 | FFIEC IT Handbook outsourcing expectations for service provider contracts |
| BSA/AML Standard Requirements | 35 | Customer due diligence, SAR, and transaction-monitoring expectations for third parties in scope |
| DORA Standard Requirements | 25 | EU Digital Operational Resilience Act ICT third-party risk, for institutions with an EU footprint |
| NCUA ISE (2023) | 30 | NCUA Information Security Examination, for credit unions |
| SOX COSO | 56 | Internal control over financial reporting and IT general controls |
| GLBA 16 CFR Part 313 | 20 | Safeguards Rule |
The full library is 68 templates spanning 4,337 curated controls, including SOC 2, ISO 27001, NIST CSF and 800-53, PCI DSS, HIPAA, and the AI-governance frameworks. See the [Control Set library](/control-library).
## Incident notification
Institutions supervised by the federal banking agencies are subject to a **36-hour** notification requirement for notification incidents (12 CFR 53 for national banks and federal savings associations, 12 CFR 225 subpart N for Board-supervised institutions, and 12 CFR 304 subpart C for FDIC-supervised institutions), and the same rules require a **bank service provider** to notify each affected banking-organization customer as soon as possible when a computer-security incident has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, covered services for four or more hours.
Coverbase supports both sides of that:
* **As your service provider**, Coverbase's incident-response process and customer-notification commitments are set out in [Contract terms and exit](/security/contract-terms), and the specific notification window applicable to your institution is agreed in your contract.
* **As your tooling**, Coverbase records each third party's own contractual notification window as a tracked obligation, so an incident at a fourth party lands against the clause that governs it, and a third party whose contract lacks a notification clause is flagged as missing it rather than assumed compliant.
## Related
<CardGroup>
<Card title="Control Set library" icon="shield-check" href="/control-library">
Every packaged framework, its control count, and its official source.
</Card>
<Card title="Contract terms and exit" icon="file-contract" href="/security/contract-terms">
Incident notification, data return and destruction, renewal and notice.
</Card>
<Card title="Evidence packaging" icon="box-archive" href="/reporting/due-diligence-file">
Producing the complete due-diligence file for one third party.
</Card>
<Card title="Audit trails" icon="list-timeline" href="/security/audit-trails">
The defensible record behind every decision.
</Card>
</CardGroup>
# Secure development
Source: https://docs.coverbase.com/security/secure-development
Our secure SDLC: review, automated gates, dependency and secret scanning, and least-privilege CI/CD.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Security is built into how we ship, not bolted on afterward. Every change to Coverbase flows through a secure software-development lifecycle (SDLC) with mandatory review and automated quality and security gates before it reaches production.
## Change management
<CardGroup>
<Card title="Peer review required" icon="users">
All code changes are made on branches and merged through pull requests. Changes require review and must pass automated checks before merge to the main branch.
</Card>
<Card title="Protected main branch" icon="shield-halved">
The production branch is protected. Direct pushes are disallowed; merges go through review and a green check suite.
</Card>
<Card title="Traceable history" icon="clock-rotate-left">
Every change is attributable to an author and a reviewer, with linear, auditable history from commit to deploy.
</Card>
<Card title="Controlled releases" icon="rocket">
Deployments are automated through CI/CD, so what runs in production is exactly what was reviewed and built.
</Card>
</CardGroup>
## Automated quality and security gates
Every pull request runs an automated check ladder before it can merge:
| Gate | What it enforces |
| - | - |
| Type checking | Static type analysis across all services (backend and frontend) catches whole classes of defects before runtime. |
| Linting and formatting | Enforced style and lint rules keep the codebase consistent and flag risky patterns. |
| Automated tests | Unit, integration, and end-to-end suites must pass. |
| Dependency scanning | Third-party dependencies are scanned for known vulnerabilities and kept current. |
| Secret scanning | Automated scanning blocks credentials and secrets from being committed. |
## Dependency and supply-chain hygiene
* Dependencies are pinned and their lockfiles are checked in CI, so the build is reproducible and a dependency cannot change underneath us silently.
* Known-vulnerable dependencies are surfaced and upgraded on a priority basis.
* CI/CD runs with least-privilege credentials scoped to the task at hand.
## Infrastructure as code
Production infrastructure is defined as code and provisioned through reviewed, version-controlled pipelines (Pulumi on AWS). Infrastructure changes go through the same review and approval path as application code, so configuration drift and unreviewed production changes are prevented.
## Separation of environments
Development, testing, and production are separated.
## Secure-by-default patterns
The platform is built around defensive patterns that are enforced in code review and by automated rules: for example, mandatory per-organization data scoping at the data-access layer, authenticated-by-default API routes, and constrained credential scopes. New code inherits these protections by construction rather than relying on each engineer to remember them.
# Support, service levels and escalation
Source: https://docs.coverbase.com/security/support-and-slas
Coverbase support channels, the P0 to P3 severity ladder with response and update commitments, the on-call escalation path, the 99.9% uptime SLO and how it is measured, and the public status page.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Coverbase's support commitments are contractual. This page states them in plain terms so you can diligence them before you sign, and hold us to them afterwards.
<Note>
The commitments below describe the standard Coverbase SLA. Your executed agreement governs, and enterprise terms can differ. Ask your account team for the SLA exhibit if you want the exact language.
</Note>
## Channels
<CardGroup>
<Card title="Product support" icon="envelope" href="mailto:support@coverbase.ai">
[support@coverbase.ai](mailto:support@coverbase.ai) for anything about using the product, and for incident reports.
</Card>
<Card title="Security" icon="shield-halved" href="mailto:security@coverbase.ai">
[security@coverbase.ai](mailto:security@coverbase.ai) for vulnerability reports, security questionnaires and documentation requests. Reports are acknowledged within one business day.
</Card>
<Card title="Your account team" icon="user-tie">
Every customer has a named account contact. Enterprise customers also have a shared channel with the Coverbase team for day-to-day questions.
</Card>
</CardGroup>
Coverbase's own status is published at [status.coverbase.com](https://status.coverbase.com), with per-component state and an incident history you can subscribe to. A person publishes every status-page incident: monitoring detects and pages, and a responder decides what customers are told.
## Severity ladder
Every issue is classified on a four-level ladder. Severity drives the response clock, the update cadence, and whether a human is woken up.
| Severity | Definition | Response | Updates | Pages on-call |
| - | - | - | - | - |
| **P0** | Sustained loss of service where critical features are unavailable for 15 minutes or more, with no reasonable workaround | **30 minutes** | Every **12 hours** until resolved, plus a root-cause analysis afterwards | **Yes**, to a phone |
| **P1** | Severe degradation short of an outage, such as sustained load times beyond 30 seconds | 12 hours | Every 24 hours | No |
| **P2** | Partial or moderate impact | 24 hours | Every 48 hours | No |
| **P3** | Minor or cosmetic | 48 hours | Every 96 hours | No |
The P0 definition names specific capabilities rather than leaving "critical" to argument. Sustained loss of any of these is a P0:
1. Access to the Coverbase dashboard
2. Modifying and saving controls
3. Creating vendor records
4. Initiating assessments
5. Uploading or requesting vendor documents
6. Reviewing issues and initiating email follow-ups
7. Receiving monitoring alerts from your monitoring rules
8. Adding or removing organization member access
## Escalation path
Escalation is automated, timed, and reached over its own path rather than through Slack, so a chat outage cannot stop a page from going out.
<Steps>
<Step title="Detection">
Synthetic checks perform each of the eight capabilities above end to end, from outside the production region, on a continuous schedule, exactly the way a customer would. Server-side alarms run alongside them to pinpoint the failing layer. A customer report is equally valid detection and follows the same path.
</Step>
<Step title="Page, immediately">
A P0 alarm rings the primary on-call engineer and the CTO at once, over a paging service reached on its own path rather than through Slack.
</Step>
<Step title="Escalate if unacknowledged">
At **10 minutes** unacknowledged, the secondary on-call is added. At **20 minutes**, the CTO alone is paged again. The ladder is deliberately built to finish inside the 30-minute response commitment rather than to land its last page on the deadline.
</Step>
<Step title="Communicate">
Customer impact goes on the status page once confirmed, without waiting to establish whether it will formally qualify as a P0. Updates follow at the cadence the severity requires.
</Step>
<Step title="Close the loop">
Every material incident is followed by a post-incident review, and a P0 carries a root-cause analysis to customers.
</Step>
</Steps>
If an issue is not progressing at the pace its severity implies, escalate to your account contact, and to Coverbase leadership through them. Every level of that ladder is a named person, not a queue.
## Uptime
Coverbase commits to **99.9% monthly uptime at a P0 level**, measured per calendar month. In an average month that is an error budget of roughly 44 minutes.
How the number is produced matters as much as the number:
* **Measured as a customer experiences it.** The primary measure for every committed capability is its synthetic check, run from outside the production region over the public internet. Server-side metrics alone cannot see frontend breakage or a sign-in lockout, because neither reaches our servers.
* **Counted conservatively.** Downtime is counted from the minute after the last passing check, so a recorded outage is never shorter than the real one. Recovery is minute-accurate.
* **No silent exclusions.** Nothing is excluded automatically, scheduled maintenance included. Where a correction is warranted it is made by hand and documented.
* **Declared incidents count.** Downtime a person observed enters the monthly number exactly as check-detected downtime does, whether or not an alarm fired.
## Related
<CardGroup>
<Card title="Contract terms and exit" icon="file-contract" href="/security/contract-terms">
Incident notification, data return and destruction, renewal and notice periods.
</Card>
<Card title="Security governance" icon="sitemap" href="/security/governance">
The incident-response and business-continuity program behind these commitments.
</Card>
<Card title="Compliance and assurance" icon="certificate" href="/security/compliance">
SOC 2 Type II, penetration testing, and how to request reports.
</Card>
<Card title="Working with Coverbase" icon="handshake" href="/security/working-with-coverbase">
Roadmap transparency, release cadence, and how customers influence what gets built.
</Card>
</CardGroup>
# Working with Coverbase
Source: https://docs.coverbase.com/security/working-with-coverbase
Company profile and viability diligence, release cadence and roadmap transparency, early access to features in development, and how customers influence what Coverbase builds.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
Some of what a buyer needs to know about Coverbase is not a feature. This page covers three of those: how you diligence us as a going concern, how you see where the product is going, and how you change it.
## Due diligence on Coverbase as a company
Coverbase is a venture-backed company headquartered in the United States, building third-party risk and procurement software for regulated enterprises. Our customers include organizations in financial services, insurance, technology and healthcare, several of whom are named publicly on [coverbase.com](https://www.coverbase.com).
For the diligence file itself:
<CardGroup>
<Card title="Financial viability" icon="chart-line">
Financial standing information, including funding position and, where your policy requires it, financial statements, is provided under NDA on request. Ask your account team, or [security@coverbase.ai](mailto:security@coverbase.ai). We are asked this regularly by supervised institutions and do not treat it as an unusual request.
</Card>
<Card title="Reference customers" icon="users">
Reference calls with customers running comparable programs, including in regulated banking and financial services, are arranged on request. Ask for a reference matched to your regulator, your program size and your integration pattern rather than to a logo.
</Card>
<Card title="Security and compliance" icon="certificate" href="/security/compliance">
SOC 2 Type II report, penetration-test attestation, completed CAIQ / SIG, subprocessor list, and BC/DR summary, all under NDA.
</Card>
<Card title="Commercial terms" icon="file-contract" href="/security/contract-terms">
Notification, exit, renewal and notice, and the SLA exhibit.
</Card>
</CardGroup>
<Tip>
If Coverbase would become a critical third party for your program, ask us the same questions you would ask any critical vendor: financial standing, key-person dependency, business continuity, exit path, and escrow if your policy requires it. We would rather answer them during the evaluation than during your first examination.
</Tip>
## Release cadence and roadmap
<CardGroup>
<Card title="Public, dated changelog" icon="clock-rotate-left" href="/changelog">
Every notable release is written up in the [changelog](/changelog), dated, with what changed and links to the documentation for it. It is public, so you can see the delivery cadence for yourself before you sign rather than taking a slide's word for it.
</Card>
<Card title="Documentation ships with the release" icon="book">
Feature documentation is updated in the same release, not months later. The changelog entry links to it. This page and the guides beside it are the current state of the product.
</Card>
<Card title="Roadmap reviews with your account team" icon="map">
Your account team walks the forward roadmap with you on a recurring cadence, under NDA, and will tell you where a capability you need sits rather than answering "on the roadmap" to everything.
</Card>
<Card title="Early access" icon="flask">
Capabilities in rollout are released behind per-organization feature flags. Customers who want a capability early can be switched on ahead of general availability.
</Card>
</CardGroup>
## Influencing what gets built
Coverbase is small enough that the people who build the product are reachable, and deliberately runs that way.
<Steps>
<Step title="Raise it with your account team">
Every customer has a named account contact who routes product requests directly to the team that owns the area. Enterprise customers have a shared channel with Coverbase staff, so a request does not have to wait for a scheduled call.
</Step>
<Step title="Bring the problem, not only the feature">
The requests that move fastest arrive as a described workflow, an examiner expectation, or a report your program has to produce. A request framed that way tells us what to build; a feature name usually does not.
</Step>
<Step title="Partner on it while it is being built">
Where a capability matters enough to your program, we will build it with you: scoped together, released to your organization behind a flag first, and iterated against your real data before general availability. Ask your account team to set that up explicitly if it is what you need.
</Step>
<Step title="Hold us to the date">
A committed date belongs in writing with your account team. Ask for it, and ask what happens if it slips.
</Step>
</Steps>
<Note>
If formal design-partner status, a named product contact, or roadmap-influence commitments matter to your evaluation, say so during the evaluation rather than after. These are arrangements we make, and they are far easier to agree while the commercial conversation is open.
</Note>
## Getting help day to day
| You need | Go to |
| - | - |
| Product help or an issue | [support@coverbase.ai](mailto:support@coverbase.ai), or your shared channel |
| Security reports, questionnaires, documentation | [security@coverbase.ai](mailto:security@coverbase.ai) |
| Platform status | [status.coverbase.com](https://status.coverbase.com) |
| Commercial, roadmap, references | Your account team |
| The severity ladder and response clocks | [Support, service levels and escalation](/security/support-and-slas) |
## Related
<CardGroup>
<Card title="Support, service levels and escalation" icon="headset" href="/security/support-and-slas">
What we commit to, and how escalation works.
</Card>
<Card title="Contract terms and exit" icon="file-contract" href="/security/contract-terms">
Notification, data return, renewal and the diligence package.
</Card>
<Card title="Changelog" icon="clock-rotate-left" href="/changelog">
What shipped, and when.
</Card>
<Card title="Trust and security overview" icon="shield-halved" href="/security/overview">
The whole trust surface in one place.
</Card>
</CardGroup>
# Admin and setup guide
Source: https://docs.coverbase.com/user-guides/admin-setup
Stand up your Coverbase environment from scratch: vendors, tags, questionnaires, scales, control sets, templates, monitoring, and integrations.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is for the TPRM program owner or administrator setting up the environment. Once setup is done, your analysts pick up the [Analyst and reviewer guide](/user-guides/analyst-reviewer).
</Info>
This guide takes you from a blank environment to a configured one. You will import vendors, build the inherent risk questionnaire (IRQ), tune scales and control sets, and configure the templates, monitoring, and integrations that everything downstream depends on.
Configuration is where the AI gets its instructions. The better this upfront work, the fewer issues your reviewers triage later. Most teams finish core setup in 1 to 2 weeks with roughly 20 hours of effort, and your Coverbase contact runs live working sessions to do it alongside you.
<Tip>
If you are new to the platform, read the short [How Coverbase thinks](/user-guides/overview#how-coverbase-thinks) primer first. The quick version: Coverbase is document-first (it measures vendor evidence against your controls), tags drive most of the automation, and configuration changes apply going forward, never retroactively.
</Tip>
## Setup checklist
Each item below is a step in this guide.
<Steps>
<Step title="Users and branding">Add your team and apply your organization's branding.</Step>
<Step title="Vendor portfolio">Import your existing vendor inventory.</Step>
<Step title="Tag structure">Create the tags that route everything.</Step>
<Step title="IRQ">Build, weight, and map your intake questionnaire.</Step>
<Step title="Scales">Configure your risk and compliance scales.</Step>
<Step title="Control sets">Upload, tune, and map your control frameworks.</Step>
<Step title="Plans and cadence">Set assessment plans and reassessment timing.</Step>
<Step title="Templates">Build report and vendor-email templates.</Step>
<Step title="Radar">Configure continuous-monitoring sources and detectors.</Step>
<Step title="Obligations">Turn on obligations and CUEC extraction.</Step>
<Step title="Integrations">Connect the Export API and external tools (optional).</Step>
</Steps>
***
## Step 1: Organization, users, and branding
This step gets your team into the platform and makes everything vendor-facing and stakeholder-facing carry your brand.
1. Go to **Configuration → Organization**, open **Members**, and choose **Invite**. Everyone in one batch of invitations gets the same role, so invite in groups:
* **Admin** has full platform access, including members, roles, integrations and organization settings.
* **Member** creates and edits vendors, assessments, findings and intake requests across the organization. Most of the risk team starts here.
* **Auxiliary Member** answers inherent-risk questionnaires, completes tasks assigned to them, and comments on records they are assigned to.
The other default roles (Siloed Member, Guest and Service Account) are described in [Permissions and roles](/user-guides/permissions-and-roles).
2. For a broader rollout, add your email domain under **Verified domains** on **General**, so people with that domain can join automatically or request to join. That saves you from creating accounts by hand while you pilot.
3. On **Branding**, set your brand. The **Logo** is a square icon shown in the app and the vendor portal header. The **Full Logo** is a wordmark or logotype used in reports and emails. **Brand color** sets the accent for the vendor portal background.
Organizations on the redesigned Organization settings find members under **People** (choose **Invite people**) and the brand on **General**, where the square mark is the **Icon** and the logotype is the **Wordmark**.
<Frame>
<img alt="Coverbase organization and branding settings" />
</Frame>
<Tip>
Vendors receiving an assessment request should see your brand, not Coverbase's. Provisioning from verified domains means your pilot team can start testing right away.
</Tip>
Logos and colors cover the visual identity. For the domain vendor email sends from and the portal is hosted on, see [White-labeling your vendor-facing domain](/user-guides/white-labeling).
***
## Step 2: Import your vendor portfolio
Loading your existing vendor inventory gives assessments, monitoring, and redundancy checks something to work against. It becomes the library you run reassessments and continuous monitoring from.
You need your vendor list with attributes like name, website, description, relationship owner, and contract dates. Your Coverbase contact can hand you the bulk-upload template, along with an enrichment workflow that fills in missing fields.
1. On the **Vendors** page, open **Actions → Import or update vendors**.
2. Choose **Download template** to see the fields, then map your existing data into it. The first sheet (vendor intake) is required and the second (service intake) is optional.
3. Upload your file.
4. Validate the result. Confirm the vendor count matches your source file, and spot-check a few records to make sure the field values populated correctly.
<Frame>
<img alt="Bulk create vendors import screen" />
</Frame>
### Update vendors you already have
The same import updates existing vendors. Use it to fill in fields across many vendors at once, for example after vendors were created with only a name.
1. On the **Vendors** page, open **Actions → Export as Excel**. Select **Include services tab in export** or **Include locations tab in export** if you want to edit those too.
2. Edit the workbook. Keep the **Vendor ID** column as exported: it matches each row to its vendor. Fill only the cells you want to change, because a blank cell leaves the current value alone.
3. Upload the edited workbook through **Actions → Import or update vendors**. The preview shows how many vendors will be created and updated, and lists any row that cannot be imported.
A row with no Vendor ID creates a new vendor. A Vendor ID that matches no vendor is reported as a problem and that row is skipped. You can edit the About fields, contacts, relationship owners, risk analysts, watchers, status, tags, inherent and residual risk levels, risk domain levels, custom fields, services and locations. Every change is recorded in the vendor's history under your name.
<Note>
Upload large workbooks in files of about 500 vendors each. Re-uploading a file that only updates vendors by Vendor ID is safe.
</Note>
<Tip>
Start with your top 100 to 200 vendors rather than the entire database. That lets you refine the configuration before scaling. You can also pre-load historical documents (SOC 2s, contracts, policies) against vendor records, so your first assessments run against real evidence instead of an empty set.
</Tip>
***
## Step 3: Create your tag structure
Tags are the routing layer of the platform. IRQ answers apply tags, and tags then decide which control sets apply, which documents are required, and which due-diligence track a vendor gets.
Design the taxonomy before the IRQ, because the IRQ is what fills it in. The structure below works well in practice. Adapt it to your program.
<CardGroup>
<Card title="Criticality" icon="gauge-high">
Standard, Important, Business Critical, Mission Critical
</Card>
<Card title="Data" icon="database">
PII, PHI, Financial, Employee, plus flow and volume tags (Inbound, Outbound, Bidirectional, High Volume, Low Volume, No Data Access)
</Card>
<Card title="Access" icon="key">
Login access, PII access, On-premise, Foreign vendor
</Card>
<Card title="Geography" icon="earth-americas">
US Only, EU/EEA, UK, APAC, International
</Card>
<Card title="Infrastructure" icon="server">
Public Cloud, Private Cloud, Hybrid, On-Premise, Not Applicable
</Card>
<Card title="Size and profile" icon="building">
Startup through Enterprise, plus SaaS, Consultant, Facilities, Financial, Operations
</Card>
</CardGroup>
To set this up, go to **Configuration → Tags**, create a tag section for each category, and add the individual tags within each section with **New tag**.
<Frame>
<img alt="Tag structure configuration grouped by category" />
</Frame>
<Note>
A plain high/medium/low rating says a vendor is risky. Tags say why it is risky and how it should be assessed, which is what the automation needs. Almost everything you configure later keys off tags: a "Foreign" tag routes to extra controls, a "PCI" tag makes a PCI AOC required, an "AI SaaS" tag can attach a different clause set.
</Note>
***
## Step 4: Build and weight your IRQ
The inherent risk questionnaire is what business requesters, and Coverbase's research agent, answer at intake. Its weights produce the inherent risk score, and its response mapping applies your tags. Aim for 15 to 25 concise questions.
1. Go to **Configuration → Questionnaires**, stay on the **Inherent Risk** tab, and choose **Create Questionnaire**, or start from a packaged template with **IRQ Library** (see [The IRQ library](/user-guides/irq-library)). Use **Actions → Bulk Import Questions** to import an existing IRQ from a spreadsheet instead of building it question by question.
2. Give every answer a **Value**: its risk weight, where higher means more risk. The sum of all maximum answer values is the risk ceiling, and a vendor's actual answers as a percentage of that ceiling is their inherent risk score.
3. Hover a question and choose **Configure write-back** to map answers to tags. Data handled outside the US applies "Foreign", card data applies "PCI", and so on. Questions built before write-back existed show **Configure Response Mapping** instead.
4. Add conditional logic where a follow-on question should only appear based on a prior answer, like asking for data-flow details only if data is exchanged.
5. Set per-question AI guidance to control what the research agent may use when it auto-answers. For example, "only source from the vendor's trust center, exclude blogs and CVE chatter."
6. Mark judgment questions as Required so the AI never auto-answers them without human input.
<Frame>
<img alt="Inherent Risk Questionnaire builder with weighted answers" />
</Frame>
<Warning>
Weight the template before your first real intake. An answer left at zero adds nothing to the score, so an unweighted IRQ makes inherent risk read artificially low across your whole portfolio, and an API vendor can score like a stationery supplier.
</Warning>
### Example: mapping answers to tags
The mapping is what powers automated routing. When someone answers "This vendor will process employee data," Coverbase applies the Employee Data tag, which then triggers specific control sets and document requests.
| Question | Answer | Tags applied | Weight |
| - | - | - | - |
| What type of data will this vendor access? | Employee PII | PII Access, Employee Data, High Volume | High |
| | Public marketing data | Low Volume, No PII | Low |
| Where is this vendor located? | European Union | EU/EEA, International | Medium |
| | United States only | US Only | Low |
### Pattern: auto-escalating vendors to Critical
A common requirement is that if a vendor answers "yes" to two or three specific questions, they should land in the strictest track regardless of overall score. Use these mechanisms together for redundancy:
* Set a **Score override** on those answers (the menu beside the option). While the answer is selected, the questionnaire's overall score cannot fall below the percentage you enter, so a single "yes" can hold the vendor in your critical band.
* Weight those questions heavily, so any "yes" pushes the score up on its own.
* Map those answers to a tag that routes the vendor to the stricter due-diligence track, with control sets and document requirements keyed to that tag.
Scored multi-select questions with precedence logic also work here. A data-elements question can max the weight the moment someone selects PAN, for instance.
***
## Step 5: Configure risk and compliance scales
Scales define the bands your program scores against. There are two: the vendor-level risk scale and the per-control compliance scale.
1. Go to **Configuration → Scoring** and open the **Risk Scoring** tab. The default bands are 0 to 25 low, 25 to 50 medium, 50 to 75 high, and 75 to 100 critical. Every threshold is adjustable, and you can add or remove tiers, collapse to three, or lower the critical threshold.
2. On the **Control Scoring** tab, review the compliance scale used on controls. The default runs from 4 (fully compliant) down to 1 (not compliant). You can rename levels, add or remove them, or make it boolean.
3. Write criteria into each level, not only labels. The criteria text is used when scores are assigned, so "one or more failing conditions met" is more useful than a bare "low."
4. Add custom assessment scales with **New Scale** on the **Control Scoring** tab if your program rates other dimensions, like RFP alignment, ESG alignment, or contractual protection.
5. Under **Risk Display** on the **Risk Scoring** tab, choose whether residual risk is shown at all (**Track residual risk**) and whether numeric scores appear next to risk levels (**Display numerical scores**). Scores are still calculated and stored either way.
<Frame>
<img alt="Risk scale configuration with adjustable bands" />
</Frame>
<Frame>
<img alt="Compliance scale configuration" />
</Frame>
<Accordion title="Common custom scales beyond compliance" icon="ruler">
* RFP alignment: Exceeds, Meets, Partially meets, Does not meet requirements
* ESG alignment: Strong, Developing, Limited, No ESG program
* Contractual protection: Strong (indemnification, insurance, SLAs), Standard, Limited, Inadequate
Different risk domains need different criteria. Your legal team evaluating contract terms uses a different scale than your InfoSec team evaluating technical controls. Custom scales let each domain score its own way while keeping the overall picture consistent.
</Accordion>
### Decide whether service scores set the vendor's score
A service-scoped assessment scores the services it covers. By default it leaves the vendor's own score alone, so a vendor can read medium while one of its services reads high.
**Risk Roll-up** changes that. It sits under **Configuration → Scoring** on the **Risk Scoring** tab, below the risk scale. There is one switch per risk type:
* **Roll up inherent risk from services**
* **Roll up residual risk from services**
With a switch on, each vendor takes the highest score among its services for that risk type, not the average.
Services with an inactive, discontinued, or denied status are excluded. Retiring the service that set the score moves the vendor to the next highest live one.
The two risk types are set separately. You can roll up residual risk and leave inherent risk manual.
<Frame>
<img alt="Risk Roll-up settings with inherent and residual switches and the Recalculate existing vendors action" />
</Frame>
<Warning>
**Turning a switch on does not change existing scores.** It applies to scores set from that point on. To apply it to vendors you already have, use **Recalculate now** under **Recalculate existing vendors**. It rewrites the score of every vendor without an override, asks you to confirm first, and cannot be undone.
</Warning>
Recalculation runs in the background, so a large portfolio takes a few minutes. With both switches off, the button reports that there is nothing to recalculate.
Individual vendors can override this setting. See [Where a vendor's score comes from](/user-guides/running-an-assessment#where-a-vendors-score-comes-from).
***
## Step 6: Upload and tune control sets
Control sets are what assessments measure against. They define what "good" looks like. Coverbase ships with SIG, NIST (CSF and AI RMF), ISO 27001, NYDFS, FFIEC, PCI DSS, DORA, and more out of the box, and your own frameworks import from a spreadsheet.
If you buy physical goods rather than software, look under **Operations & Supply Chain** in the **Vendor Controls Library**. Those templates ask a supplier whether it can keep your production line fed (continuity testing, alternate sourcing, batch traceability, chain of custody, restricted substances) rather than how it secures a network. The [Control Set library](/control-library) lists all of them.
<Frame>
<img alt="Controls page with a control set open and the New Control Set menu showing Upload Spreadsheet" />
</Frame>
### Importing your own controls
1. Go to **Configuration → Controls** and click **New Control Set → Upload Spreadsheet**. Download the template workbook and the tips document from that dialog, which always holds the current version. In the workbook, the **Controls** tab is the one that gets imported; the **Instructions** tab carries the tips, and the **Document Types** and **Risk Domains** tabs are there for reference.
2. Use an LLM to convert your existing framework (from your GRC tool, a spreadsheet, wherever it lives) into the template format. Paste your controls plus the tips doc and ask for the conversion.
3. Upload one control set at a time and verify the import. Start with your two or three most critical frameworks.
<Frame>
<img alt="Upload Control Set dialog with a Download template button and a tips link" />
</Frame>
### Per-set configuration
Every control has three parts: the expectation (what you are measuring), the question (how it would be asked of a vendor if evidence is missing), and the guidance (how the AI should evaluate it). Then, per set:
* Applicability: map which tags and inherent-risk levels this set applies to. This is what makes assessment assignment automatic.
* Risk domains: assign controls to domains like InfoSec, compliance, or operational resilience, so review work can later be split across specialists.
* Strictness: set the evaluation toggle (lenient, standard, or strict) per set.
* Evidence sources: choose what the AI may draw on per control, from specific document types to web search to a vendor's Vendor Intelligence. These combine and can be prioritized, so you might put the information security policy first and web search as a fallback.
* Minimum credibility: on each web-search source, set how accountable a publisher has to be before its page can be cited: **No minimum**, **Reputable** (the default), or **Authoritative**. Pages below the bar are discarded before the AI reads them. See [Evidence quality and source credibility](/user-guides/evidence-quality) for the scale, where to tighten it, and what it does not cover.
* Restrict evidence to these sources: on by default once you add evidence sources at the set level, this keeps the analysis inside the sources you listed. Turn it off when you want to ask the vendor for particular document types without narrowing what the AI may read. The sources still drive the portal request and stay the AI's first stop, but other submitted documents remain admissible. Evidence sources set on an individual control always restrict that control.
* Document requirements: mark documents required or suggested. Required blocks portal submission until the document is uploaded, so use it sparingly.
<Accordion title="A document-requirements pattern that works" icon="file-check">
SOC 2 and pen test required. PCI AOC required only for PCI-tagged vendors. A bridge letter left as a suggested remediation when a SOC 2 is past your currency window. Everything else suggested. Default to suggested unless it is a hard gate.
</Accordion>
### Per-control tuning
Open any control to edit its expectation, weight, and guidance. Guidance is where conditional logic and exceptions live, like "mark fully compliant if the vendor is not a professional services company with a physical on-site presence," or "accept an infosec training attestation as sufficient evidence."
<Tip>
You do not have to write guidance up front. Reviewers refine it from real results using Correct the AI (see the [Analyst and reviewer guide](/user-guides/analyst-reviewer#step-4-correct-the-ai)), and every accepted correction applies to all future assessments. Specific guidance is more effective than raising the global strictness toggle, and easier to defend to a regulator.
</Tip>
<Note>
Not every framework covers every topic. NIST CSF, for example, does not explicitly cover penetration testing. When your program cares about something a framework does not name, add a control for it and point the guidance at the specific evidence.
</Note>
***
## Step 7: Assessment plans and reassessment cadence
This step decides which assessment a vendor gets, and when they get looked at again.
* Build assessment plans that bundle control sets by tier, so high and critical vendors get the fuller plan. Plans can be assigned statically or dynamically off tags and inherent risk.
* Set the reassessment cadence under **Periodic Re-assessment Settings** in **Configuration → Assessment Settings → Reassessments**. The **Timeline** sets how many days before the reassessment date stakeholder reminders go out, document collection starts, and the assessment should be ready for review. Each **Reassessment rule** names an assessment plan, the risk levels it covers, and the **Months between reassessments**. Rules match suppliers on inherent risk level by default; set **Match suppliers on** to residual risk level to key off residual instead (a supplier with no residual level yet falls back to inherent). A vendor's next reassessment date can still be changed by hand.
* Layer on trigger-based reassessments so a Radar event or a risk-score change can open an off-cycle review automatically.
* To have the relationship owner confirm inherent risk before each reassessment, turn on **Before a Reassessment Starts** in the plan. The owner gets last cycle's IRQ answers to confirm or change, and the plan picks questionnaires from the refreshed inherent risk. See [Confirm inherent risk before a reassessment](/user-guides/reassessment-irq-review).
<Frame>
<img alt="Assessment plans configuration" />
</Frame>
<Frame>
<img alt="Edit assessment plan dialog with default control sets, conditional rules and the Configure reassessment rules link" />
</Frame>
<Accordion title="A sensible starting cadence" icon="calendar-days">
* Critical: every 12 months
* High: every 24 months
* Medium: every 36 months
* Low: manual only
Manual reassessment tracking goes stale at scale and vendors slip through. Automated schedules keep the oversight consistent without the admin overhead.
</Accordion>
***
## Step 8: Report and email templates
This step makes every output, whether an assessment readout or a vendor email, land in your organization's format and voice.
For report templates, go to **Configuration → Assessment Settings → Reports** and turn on **Assessment report templates**. Build a branded template using tokens (fields from the assessment and vendor record) plus custom AI prompts for freeform sections, like "give a meaningful analysis of the limitation of liability as it relates to their DPA." If you do not have a house format yet, start from the Coverbase best-practice template with your branding.
<Frame>
<img alt="Assessment report template builder" />
</Frame>
Whoever writes the `.docx` will want the full reference open alongside it. Tokens are called **placeholders** in those pages.
<CardGroup>
<Card title="Custom Word report templates" icon="file-word" href="/reporting/assessment-report-templates">
How to author the `.docx`: placeholder syntax, AI prompt sections, repeating findings tables, signature anchors, and what happens when a placeholder cannot be filled.
</Card>
<Card title="Placeholder reference" icon="brackets-curly" href="/reporting/template-placeholders">
Every placeholder available, what it resolves to, and how each value is formatted.
</Card>
</CardGroup>
<Note>
Three exports come built in: Standard PDF, Executive Summary, and Full (every control with all evidence, the one examiners like).
</Note>
For vendor email, go to **Configuration → Communications**. **Organization identity** at the top sets the sender name, the sender address and the inbound contact vendors should reach. The **Templates** list holds the wording of portal invitations and follow-ups: each template carries AI instructions, default CC and BCC recipients (add the internal requester here), and attachments. Attach a pre-signed MNDA to invitations so legal back-and-forth does not stall document sharing. The reminder cadence (every two days, for example) lives on the portal template under **Configuration → Portals**.
<Frame>
<img alt="Communications settings with the organization identity and the email templates list" />
</Frame>
***
## Step 9: Configure Radar (continuous monitoring)
Radar is the external intelligence layer. Sources feed detectors, and detectors fire on the events that matter, which reach your analysts as signals. Sources and detectors live under **Configuration → Radar**. The **Configurations** menu on the Radar page opens its **Detectors**, **Sources** and **Reassessments** tabs.
1. Review the out-of-the-box sources: SEC filings, CVE feeds, CISA advisories, and security and financial news, all pulled several times a day. Add any public RSS feed at no extra cost, or connect a ratings platform like Black Kite as an API source.
2. Create detectors around what you act on, such as breaches and vulnerabilities, supply-chain disruption, or SEC and regulatory actions. Each detector takes plain-language guidance, example events to focus on, impacted risk domains, and a severity threshold. Switch on its risk impact, and set the point range, if acting on its signals should move residual risk (see [risk propagation](/products/supplier-radar#risk-propagation)).
3. Test each detector before you enable it, and start with tight severity thresholds.
<Frame>
<img alt="Radar detector configuration list" />
</Frame>
<Frame>
<img alt="Radar sources configuration" />
</Frame>
<Warning>
The failure mode of continuous monitoring is noise. One event makes one signal however many detectors fire, but a loose detector still fires on every routine patch note, and a single well-covered vendor can produce a dozen of those in a week. Keep detectors narrow and severities high at first, watch what fires for two weeks, then loosen. Fourth-party relationships are extracted automatically from SOC 2s and subprocessor lists, so one event can implicate many vendors at once.
</Warning>
***
## Step 10: Enable obligations extraction
This step turns on extraction of what vendors require of you: CUECs from SOC reports (pulled verbatim) and shared responsibilities from contracts, DPAs, and terms.
1. Go to **Configuration → Obligations** and turn on **Auto-create obligations from vendor CUECs** (from SOC reports) and **Auto-create obligations from contract shared responsibilities** (from contracts).
2. Re-trigger analysis on documents you uploaded before you enabled this. Extraction only runs on documents processed after the setting is on.
3. Optionally, upload your internal control set so extracted obligations can be checked automatically against controls you already have in place. If a matched obligation should wait for a business unit to confirm it before it counts as satisfied, also turn on **Require business-unit acknowledgement**.
<Frame>
<img alt="Obligations settings with the two auto-create switches and the business-unit acknowledgement switch" />
</Frame>
<Note>
The full obligations workflow (validation, ownership, and business-unit acknowledgement) is in the [Obligations guide](/user-guides/obligations).
</Note>
***
## Step 11: Integrations and Export API (optional)
This step exposes Coverbase data to external systems like GRC platforms, ticketing, and data warehouses.
1. Go to **Configuration → Organization → API keys** and choose **Add new key**. Name it, set an expiration, and store the bearer token securely: a key is shown once, when it is created.
2. Go to **Configuration → Coverbase API**, stay on the **Export API** tab, and choose **New Export Report**. Pick the object the report returns and map which fields to expose. Note the GET endpoint shown on screen.
3. For GRC integrations (findings out to your audit platform, controls back in), scope what needs to flow with your Coverbase contact, whether that is findings, residual-risk ratings, or control-environment scores.
4. To have events pushed to your systems as they happen, add an endpoint under **Configuration → Webhooks**. See [Webhooks](/user-guides/webhooks).
<Frame>
<img alt="Export API configuration" />
</Frame>
<Note>
External systems can pull data through the API, and [webhooks](/user-guides/webhooks) push events to them as they happen. You can also connect vendor status pages for SLA-adjacent monitoring. For the full developer reference, see the [Export API concepts](/export-api-concepts).
</Note>
***
## Admin quick reference
Five rules:
<CardGroup>
<Card title="Changes are not retroactive" icon="clock-rotate-left">
IRQ and control-set edits apply going forward. Use a bulk reassessment to apply new standards to existing vendors. Control sets are version-controlled, so an edit creates a new version.
</Card>
<Card title="Weight before you launch" icon="scale-unbalanced">
Zero-value IRQ scores are the most common cause of "why is everything low risk?"
</Card>
<Card title="Tags drive everything" icon="tags">
Control-set applicability, document requirements, clause sets, and escalation tracks all key off tags. Keep the taxonomy clean.
</Card>
<Card title="Required means blocking" icon="lock">
A required document stops portal submission entirely. Default to suggested unless it is a hard gate like a PCI AOC.
</Card>
<Card title="Guidance beats strictness" icon="wand-magic-sparkles">
Specific control guidance (who is exempt, what evidence counts) is more effective than the global strictness toggle, and easier to defend to a regulator.
</Card>
</CardGroup>
## Frequently asked questions
<AccordionGroup>
<Accordion title="How long does initial setup take?">
Most organizations finish core configuration in 1 to 2 weeks with roughly 20 hours of effort. Organizations with complex control sets or a lot of integrations may need 4 to 6 weeks.
</Accordion>
<Accordion title="Do we need to configure all control frameworks at once?">
No. Start with your two or three most critical frameworks, usually NIST CSF and one industry-specific standard. Add more as your program matures.
</Accordion>
<Accordion title="What if we don't have an existing IRQ?">
Use Coverbase's enhanced template. It includes industry best practices and can be customized to your requirements.
</Accordion>
<Accordion title="How does AI assessment work?">
When you start an assessment, Coverbase searches the vendor's website, trust center, and security documentation, analyzes uploaded documents like SOC 2 reports and contracts, pulls data from integrated services, and evaluates all of it against your control requirements. It surfaces gaps as issues for human review and generates follow-up questions only for what it could not verify.
</Accordion>
<Accordion title="What if the AI makes a mistake?">
Coverbase assumes the AI will make errors. Every assessment includes a human review phase where your team validates findings before finalizing, and every result carries citations, so errors are easy to spot and correct. In practice the AI drafts most of the assessment and your team quality-checks the rest.
</Accordion>
</AccordionGroup>
***
## You're set up. Now run the work
With the environment configured, your analysts can start assessing vendors.
<CardGroup>
<Card title="Analyst and reviewer guide" icon="user-check" href="/user-guides/analyst-reviewer">
The day-to-day: triage, assess, review, correct, follow up, and report.
</Card>
<Card title="Assessment quick reference" icon="bolt" href="/user-guides/assessment-quick-reference">
A one-page cheat sheet to keep open while you work.
</Card>
</CardGroup>
<Card title="Need help?" icon="envelope" href="mailto:support@coverbase.ai">
Email [support@coverbase.ai](mailto:support@coverbase.ai), or ask your Coverbase contact to run a live working session with your team.
</Card>
# Agent Ledger
Source: https://docs.coverbase.com/user-guides/agent-ledger
Read the Agent Ledger, accept or reject an agent's action, choose what agents may do without a person, turn on personal data redaction before model calls, manage learning from your reviewers' corrections, and export the ledger for an audit.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Configuration → Agent Ledger**. It sits beside [Permissions and roles](/user-guides/permissions-and-roles) and the [AI governance](/security/ai-governance) security page. For what the module is, see [Agent Ledger and AI governance](/products/agent-ledger).
</Info>
<Note>
Your Coverbase representative turns on the third-party lifecycle features, including the Agent Ledger, for your organization.
</Note>
The Agent Ledger records every action an AI agent takes on your organization's data, and holds the settings that decide what agents may do on their own.
The mistake people make most often is turning on learning before anyone has looked at the examples. Learning uses every enabled example. Read **Learned examples** first and switch off any correction you would not want repeated.
Open **Configuration** and choose **Agent Ledger**. Changing settings needs a role that can change organization settings.
## Step 1: Read the ledger
**Actions** lists what agents did, newest first, with **Time**, **Agent**, **Action**, **Confidence**, what it **Read**, and the **Human Decision**. Search, filter by agent, action, decision, outcome, record type, date or confidence, or show only actions **Awaiting decision**. The header counts today's actions.
<Frame>
<img alt="Agent Ledger page listing actions by the evidence, monitoring, radar and intake agents with confidence scores and decisions such as Accepted, Applied under org policy and Awaiting review, beside the agent policy switches and the Privacy panel" />
</Frame>
| Agent | Records |
| - | - |
| **Evidence agent** | Control evaluations, document analysis, the Zero Touch review and claim checks |
| **Intake agent** | Vendor matching, question planning and follow-up suggestions during intake, and the Intake Agent reading requests from messages |
| **Drafting agent** | Questionnaire answers drafted in the portal |
| **Contract agent** | Contract clause reviews |
| **Risk agent** | Risk report narratives |
| **Radar agent** | Radar signal summaries |
| **Monitoring agent** | Monitoring plans re-timed from signals under your policy, or held back by it |
Open a row to see the **Record** it acted on, what it **Read**, what it **Cited**, its **Confidence**, the **Models** it called and how many, and how many personal details were redacted.
## Step 2: Record a decision
On an action awaiting review, choose **Accept**, **Edited and accepted** or **Reject**, and confirm. A **Note** is saved with your decision in the ledger and its audit export. Rejecting needs one. The row then reads, for example, **Accepted by** and the person's name.
To decide several at once, select them and choose **Accept** or **Reject**. Only completed actions nobody has decided are changed. The result says how many were left as they were.
An action taken under one of your policies reads **Applied under org policy**, one a policy held back reads **Held back by org policy**, and a failed action reads **Failed**.
## Step 3: Choose what agents may do
Under **What Agents May Do**, switch on only the actions you are content for an agent to take without a person. Only admins can change them. Each switch is enforced where the agent acts:
| Policy | On | Off |
| - | - | - |
| **Re-time monitoring from feed signals** (off by default) | Moves monitoring activities forward when a Radar alert or reassessment trigger fires, under your [signal re-timing rule](/user-guides/monitoring-plans#step-4-keep-or-revert-a-signal-move). | Signals are noted in the ledger and plans stay as scheduled. |
| **Propose diligence reuse** (on by default) | Proposes reusing a similar engagement's due diligence at the Front Door. | Reviewers start from full due diligence. |
**Auto-close low tier reassessments with no changes** and **Send anything to a vendor without review** read **No agent does this yet, so it stays off**. **Accept risk or close an issue** reads **Always needs a person; this cannot be delegated**.
## Step 4: Decide on redaction
Under **Privacy**, **Redact personal data before model calls** is off by default. Turned on, email addresses, phone numbers, account and tax numbers (IBANs and US tax IDs), and the full names of your users and your vendors' contacts become placeholders before a request reaches the model, and the answer is restored before anyone sees it.
Keep in mind:
* Redaction does not reach inside images or attached documents, such as a PDF the model reads directly.
* If Coverbase cannot confirm the setting for your organization, the model call fails rather than going out unredacted.
The privacy panel also states where your models run, that customer data is not used for training, and that bank and tax identifiers are sealed per field.
## Step 5: Manage learning
When a reviewer overturns a control evaluation, clearing or flagging an issue, a daily job turns the correction into a learned example for that control. **Learned examples** lists each with the **Control**, the **Reviewer Decision** (**Cleared an issue** or **Flagged an issue**), the **Reviewer Note** and **Use**.
<Steps>
<Step title="Review the examples">
Switch off **Use this example** on any correction that should not be repeated. **Refresh from overrides** collects new corrections now instead of waiting a day.
</Step>
<Step title="Write guidance">
Under **Evaluation Guidance**, describe how your organization reads its controls, for example which evidence you accept for a vendor's attestation. It applies to every control evaluation. A control's own guidance wins where the two differ. Click **Save guidance**.
</Step>
<Step title="Turn it on">
Turn on **Use in evaluations**. From then on, a control's evaluation uses up to five of its enabled examples and your guidance. With it off, evaluations run unchanged.
</Step>
</Steps>
## Step 6: Export for an audit
Filter the ledger to what the audit needs (agent, action, decision, outcome, record type, date or confidence), then click **Export filtered for audit** (**Export for audit** with no filter set). The CSV is prepared in the background, up to 50,000 actions, and downloads when it is ready. You are also notified. Each row carries the citations, models, redaction count and human decision. A value a spreadsheet would run as a formula is written as text.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **Agent Ledger** under **Configuration** | The third-party lifecycle features are not on for your organization. | Ask your Coverbase representative. |
| **No agent actions match these filters** | The filters exclude everything. | Widen or clear the filters. |
| **Accept risk or close an issue** cannot be switched on | It always needs a person. | Expected. |
| An answer contains a placeholder such as `[[PERSON:...]]` | The model rewrote a placeholder so it could not be restored. | Run the action again. Report repeated cases to your Coverbase representative. |
| A model call failed after redaction was turned on | The call used a request type redaction does not cover, or the setting could not be read. | Report it to your Coverbase representative with the time and the action. |
| **No reviewer overrides yet.** | No reviewer has changed an evaluation's verdict in the last 180 days. | Expected. Examples appear as reviewers correct evaluations. |
| The export fails with a message to narrow it | More than 50,000 actions match. | Narrow the filters, for example to a shorter date range. |
| Signals did not move any monitoring plan | **Re-time monitoring from feed signals** is off. | Turn it on. The ledger shows what was held back. |
## Related
<CardGroup>
<Card title="AI governance" icon="brain-circuit" href="/security/ai-governance">
How models are selected, tested and constrained.
</Card>
<Card title="Agent Ledger and AI governance" icon="book-bookmark" href="/products/agent-ledger">
What the module does.
</Card>
<Card title="The analyst and reviewer guide" icon="user-check" href="/user-guides/analyst-reviewer">
Correcting an evaluation, which feeds learning.
</Card>
<Card title="Monitoring plans" icon="calendar-check" href="/user-guides/monitoring-plans">
Signal re-timing, one of the agent policies.
</Card>
</CardGroup>
# Analyst and reviewer guide
Source: https://docs.coverbase.com/user-guides/analyst-reviewer
The day-to-day of vendor risk in Coverbase: triage intake, launch assessments, review and correct AI findings, follow up with vendors, and close the loop.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is for analysts, reviewers, and InfoSec SMEs doing daily vendor reviews. It assumes your environment is already configured. If you are setting it up, start with the [Admin and setup guide](/user-guides/admin-setup).
This page is the wide view of the job. For a screen-by-screen walkthrough of one assessment from intake to export, see [How to run an assessment](/user-guides/running-an-assessment).
</Info>
Coverbase reads vendor documents and measures them against your controls, so your job shifts from hunting through PDFs to judging results. A typical assessment measures a hundred-plus controls and raises a handful of material issues. In one real case, 111 controls produced 5.
This is the loop you run:
<Steps>
<Step title="Triage intake">Review enriched new-vendor requests.</Step>
<Step title="Launch assessment">Attach control sets and let analysis run.</Step>
<Step title="Review issues">Judge the material items, evidence in hand.</Step>
<Step title="Correct the AI">Fix wrong or noisy results for good.</Step>
<Step title="Follow up">Ask vendors only about genuine gaps.</Step>
<Step title="Disposition and report">Decide, complete, and export.</Step>
<Step title="Watch Radar">Turn monitoring signal into action.</Step>
</Steps>
<Tip>
Two habits matter most. Validate against source language: every result carries citations you can click through. Correct the AI when it is wrong: corrections are permanent, and the issue count drops with every cycle.
</Tip>
***
## Step 1: Triage new vendor requests
New requests arrive from business requesters already enriched with sanctions, financials, security posture, and a redundancy check against your existing portfolio. Most IRQ questions come pre-answered by the research agent.
1. Open the pending submission and scan the enrichment readout. A red flag on sanctions is a fuzzy match to investigate, and an unknown vendor with no public presence also flags red.
2. Check the redundancy readout. If the vendor, or a comparable tool, already exists in your portfolio, this may be a new service on an existing record rather than a new onboarding.
3. Review the auto-answered IRQ. A "limited information" flag means the AI could not confirm authoritatively, not that a problem exists. Click the reviewed checkbox on each answer you validate. Your name and timestamp are recorded.
4. Answer anything flagged for manual input, usually the judgment questions your admin marked Required.
5. If something is ambiguous, use Request Clarification to send a templated email back to the requester before approving.
6. If the requester misidentified an existing vendor, approve the submission and use the vendor record merge function to consolidate it under the parent record.
7. Accept to kick off onboarding. The right assessment plan attaches automatically based on tags and inherent risk.
The requester sees three steps on their side (**Select Vendor**, **Additional Information**, **Review Questionnaires**), and Coverbase does most of the typing for them. Two parts of that flow change what lands in your queue:
* **Pre-Qualification** runs on the vendor name at step 1 and tells the requester if the vendor is already onboarded, or if an approved vendor already covers the use case. It is why some requests never reach you.
* **The autofilled IRQ** at step 3 arrives with a confidence badge per answer (green *High confidence*, amber *Review this response*) and the reasoning and sources behind each one. Work the amber ones first. Amber means Coverbase was not confident, and the reasoning usually names what was missing.
The requester cannot edit responses after submission, so anything wrong is yours to correct on the way through.
<Tip>
Requests can also arrive from an AI assistant rather than the portal. Same session, same queue, same enrichment; see [Vendor intake in chat](/mcp/vendor-intake). You can work this queue that way too, taking each pending submission in turn and approving, rejecting, or requesting follow-up with confirmation. If you want to point a requester at the requester-side walkthrough, send them [Requesting a new vendor](/user-guides/requesting-a-vendor).
</Tip>
<Frame>
<img alt="Intake queue of pending vendor requests" />
</Frame>
<Frame>
<img alt="Intake submission detail with enrichment and auto-answered questions" />
</Frame>
<Note>
Inherent risk is the vendor's weighted answers as a percentage of the maximum possible. If a score looks wrong for the vendor type, say an API vendor scoring low, flag it to your admin. That is a weighting fix.
</Note>
***
## Step 2: Launch an assessment
Launching an assessment opens the review. It attaches control sets, kicks off document collection, and runs the analysis.
1. Open the vendor record, then go to **Assessments → New Assessment**. Choose vendor-level or service-level scope. Multiple assessments can coexist, and one assessment can carry multiple control sets at once, like SIG core plus your own InfoSec set.
2. Pick the **Assessment Plan**. Control sets and questionnaires are not chosen assessment by assessment; they come from the plan. Selecting one shows a summary: how many control sets and questionnaires, manual or automatic collection, whether it targets residual risk, and who reviews it. Read that summary to catch a plan that is heavier or lighter than the vendor warrants. Leaving it on **None** creates an assessment with no control sets attached.
3. Add more than one vendor if you are starting a batch. Each gets its own assessment from the same plan, which is how annual reviews are best run. The button reads **Create Assessments** for that reason.
4. Let evidence collection run. The **Documents** tab offers five routes that combine freely, each showing how much is available before you click: **Import from existing vendor docs**, **Request from vendor** (the portal, with its current status), **Request automatic collection**, **Import from Coverbase Library** ([documents Coverbase collected itself](/products/document-library), often substantial for well-known vendors), and **Retrieve from Trust Center** (needs a Trust Center URL on the vendor record). Below the cards, **Upload vendor documents** takes files you hold yourself. In automatic mode Coverbase pulls from its library first, then scrapes the vendor's trust center for anything ungated (it form-fills access requests for gated documents), before falling back to asking the vendor.
5. Where the vendor has to be engaged, send the portal invitation with a due date. Reminders and the pre-signed MNDA your admin configured go out automatically. The vendor cannot submit until the required items are done, and when they upload, analysis of the affected controls starts on its own.
6. Analysis takes roughly 5 to 10 minutes on a small evidence set and 20 to 30 minutes when there is a lot to read. A long SOC 2 takes considerably longer than a certificate of insurance. Large control sets add to it, and a full SIG core is around 300 questions. You do not need to keep the tab open.
The left panel tracks the assessment through its stages (**Collecting Documents**, **Analyzing Controls**, **Review Results**, then any stages your organization has added after them, such as a quality-control pass) and always tells you what it is waiting for, with a shortcut into that work.
<Frame>
<img alt="Assessment workspace showing control sets and lifecycle" />
</Frame>
<Note>
A vendor uploading a blank or junk document does not slip through. The AI analysis fails it automatically. Trust-center scraping lands documents about 20 to 30% of the time, so the portal stays the primary path for smaller and historical vendors.
</Note>
***
## Step 3: Review the results
The AI has measured every document against every control and raised issues where evidence is missing or contradicts the expectation. Work through the results in this order.
1. Start with the issues, not every result. The **Issues** tab opens filtered to the results raised as issues, so triage the material items first.
2. Turn on **Assigned to me** to filter to your controls. Issues can be assigned per risk domain (InfoSec to InfoSec SMEs, and so on) or round-robin across the team.
3. Open each issue. You see the expectation, the guidance the AI used, and the analysis citing the specific evidence. Click through to the source language to validate. Never take the summary on faith for a material item.
4. Spot-check compliant controls too, especially early on. Passes show the same full evidence chain, plus web-sourced supporting articles, and this is how you catch false negatives while you build trust in the output.
5. Where two control sets overlap, say SIG core and the out-of-box SOC 2 set raising the same gap twice, mark the duplicate as not an issue and tell your admin to drop the redundant set from future assessments.
**Getting around the workspace.** Eleven tabs run across the top; most days you need the first two. **Summary** carries the recommendation, the score and its compliance band, review progress, and the risk domain table: Overall Vendor Risk plus a row per domain with inherent risk, residual risk, and the assigned reviewer. Rows reading "Not set" against residual risk have not been reviewed yet, so that column is your to-do list. **Issues** holds one result per control, opening filtered to the ones raised as issues. The remaining nine (Controls, Findings, Emails, Work Queue, Documents, Activity, Notes, Properties, SLAs) carry supporting detail and the audit trail.
**Working the Issues tab.** Three toggles switch between all results, issues only, and open follow-ups, each with a count. **Group by** defaults to **Control Section**, so results cluster by control set and section with that section's reviewers on the group header. Select rows, or **Select all**, and an action bar appears with everything you can do at once: **Resolve** (mark as mitigated or accept risk), **Add Finding**, **Create follow-ups**, **Delete follow-ups**, **Preserve**, and **Draft new email**. On a large assessment, bulk-drafting follow-ups for every missing-document issue is one action rather than a hundred.
**Judging web evidence.** Evidence pulled from the public web carries a credibility badge (**Authoritative**, **Reputable**, or **Unreliable**) naming how accountable its publisher is, with the reason on hover, plus the page's publication date and how old it was when it was cited. Anything below the minimum your admin set was already discarded before the AI read it, so what you see has passed the bar. See [Evidence quality and source credibility](/user-guides/evidence-quality) when a control is resting on web evidence you want to scrutinize, or when a customer asks how source quality is controlled.
**Inside a result.** The left column shows the expectation, the question as the vendor sees it, the guidance, the source control set, and the weight, with the evaluation and its bulleted analysis beneath. Four controls sit above the evaluation: **Correct the AI**, **Rerun** (evaluates the control again as it stands), **Preserve** (pins a result so later runs do not overwrite it), and **Edit**. The right column holds Evidence, Follow-up, Findings, and Activity, with prev/next controls so you can work straight through the list without going back. Each piece of evidence names its source document and page, quotes the passage, and previews the page with the passage highlighted. The highlight is the evidence you point to when an examiner asks why a control passed.
<Frame>
<img alt="Assessment review results grouped by control set" />
</Frame>
<Frame>
<img alt="Issue detail view with cited evidence and source document" />
</Frame>
***
## Step 4: Correct the AI
Correct the AI turns a wrong or noisy result into a permanent change. You edit the control's guidance, rerun it on the spot, and if you accept, the change applies to every future assessment.
1. On the issue, choose Correct the AI.
2. Write the missing condition into the guidance. Be specific.
3. Rerun the control and confirm the result changes as expected.
4. Accept to save globally, or discard.
<Frame>
<img alt="Correct the AI guidance editor" />
</Frame>
<Accordion title="Real corrections from live reviews" icon="wand-magic-sparkles">
* A clean desk policy flagged for a SaaS vendor. Added "mark fully compliant if the vendor is not a professional services or contracting company with a physical on-site presence." The rerun resolved to no issue.
* SOC 2 currency. Tightened the default 12-month window to 6 months on the control, and the draft vendor follow-up regenerated itself to reflect the new window.
* Employment contractual agreements. Added "accept an information security training attestation as sufficient evidence." The issue resolved and saved for all future assessments.
</Accordion>
<Warning>
Be specific, not lenient. Distinguish a public company from a startup, or a SaaS vendor from professional services, rather than broadly relaxing a control. Specific guidance is defensible to a regulator, and it keeps the same false positive from coming back.
</Warning>
***
## Step 5: Follow up with the vendor
For genuine gaps, you send the vendor a contextualized question that references what they already submitted, through the portal.
1. On an issue, choose Draft Follow-up and use AI Autofill. It writes the question in context ("we reviewed your SOC 2 and it doesn't address X") rather than pasting raw control text, which vendors respond to far better.
2. For volume, select all issues, then Create Follow-ups. AI Autofill runs across the batch. Set the portal due date and send in one step.
3. Pick the email template and add any vendor-specific instructions. The internal requester is CC'd automatically.
4. The vendor answers and uploads new evidence directly in the portal, and responses flow back onto the issues.
The mechanics:
* **Saving a follow-up creates a draft. It does not send.** Follow-ups are drafted individually and sent together, so the vendor gets one consolidated request instead of a trickle of emails. The bar at the top of the Issues tab shows how many drafts are waiting, alongside **Configure portal** (what the vendor sees) and **Manage sent follow-ups** (what is already out).
* **Name the evidence you want.** Under **Required document types**, say what the vendor should attach, so the request is specific rather than "please send evidence". **Use control question and response** reuses the original control wording if the autofilled version is not right.
* **Some vendors prefer a spreadsheet.** **Download workbook** and **Import responses** on the Issues tab let a vendor work offline and come back in.
* **Reanalysis is narrow.** When the vendor submits, only the controls selected for follow-up run again. A result that comes back reads **Response received** and its analysis is rewritten to account for what the vendor said, often moving from *Not Compliant* to *Fully Compliant* where the gap was documentation rather than practice. To re-evaluate everything from scratch, say after changing the plan or control sets, use the rerun option from the assessment **Actions** menu instead.
<Frame>
<img alt="Draft follow-up with AI autofill" />
</Frame>
<Tip>
Pace yourself. Go one by one for your first assessments, since reviewing each drafted follow-up is how you tune guidance and tone. Switch to bulk once you trust the output.
</Tip>
***
## Step 6: Reviews, disposition, and reporting
This closes the review. Domain reviewers sign off, every remaining issue gets a decision, the vendor gets a status and a reassessment date, and the record becomes a report.
### Domain reviews and quality control
Each risk domain can carry its own reviewer, which is what lets several teams work one assessment: InfoSec on the security domains, Legal on the contractual ones, Compliance on regulatory. The Summary tab reports progress as a count of completed reviews.
A reviewer opens their domain with **Start review**. Until someone does, the domain shows *Not started* and its residual risk stays "Not set".
* Reviewers are set per domain or control set and can be changed at any time.
* Reviewers are notified when results are ready for them, and risk analysts and administrators can resend reminders.
* Your organization can optionally prevent anyone who is not a risk analyst or administrator from completing assessments.
Once the reviews are in, the assessment moves on to any stage your organization added after **Review Results** (a quality-control pass, for example) before it is completed.
<Warning>
Depending on configuration, **Complete Assessment** stays disabled until the domain reviews are finished. If the button is grayed out, look at the review column rather than the score.
</Warning>
### Dispositioning issues
You have three dispositions per issue:
<CardGroup>
<Card title="Accept the risk" icon="circle-check">
Records a timestamped rationale on the record, audit-backed.
</Card>
<Card title="Keep the follow-up open" icon="clock">
The issue stays pending vendor response.
</Card>
<Card title="Promote to a finding" icon="flag">
Use Action, then Add Finding, with AI autofill for consistent language. Assign a named owner and a due date. Findings persist beyond the assessment.
</Card>
</CardGroup>
### Completing and exporting
Click **Complete Assessment** on the Summary tab. The dialog asks for four things:
1. **Action**: approve, reject, or whichever outcomes your organization uses.
2. **Vendor Status**: where this leaves the vendor in its lifecycle, for example *Active*. Custom statuses are supported.
3. **Next Vendor Reassessment Date**: set for you from the risk tier and the completion date, typically a year out, and fully overridable if this vendor needs watching sooner. Anything unresolved converts to findings rather than getting deleted.
4. **Recommendation**: the written conclusion that carries into exports, so write it properly rather than leaving it thin.
**Risk Scoring Changes** expands to show how this assessment moved the vendor's scores. Check it before you confirm. On a service-scoped assessment the change applies to the services. It reaches the vendor only if your organization rolls service scores up.
Then export. **Export Report** offers four formats: PDF, Excel, CSV, and Word. Match the format to the audience: PDF for anything leaving the company, Excel or CSV when someone wants to sort and filter the results themselves, and Word when the output has to drop into an existing house template. Your organization's branded Word template fills itself in automatically; see [Custom Word report templates](/reporting/assessment-report-templates) if you need to change what it pulls in.
Scope matters as much as format: Standard for most reviews, Executive Summary for leadership, and Full (every control with all evidence) when an examiner asks. The fullest export includes every result, all document evidence, the activity log, follow-ups, and notes, and can run to hundreds of pages.
<Frame>
<img alt="Completed assessment summary with risk scores and recommendation" />
</Frame>
***
## Step 7: Contracts and clause reviews
The contracts module extracts key terms from MSAs, SOWs, and DPAs (value, effective date, term and renewal, indemnity, billing, data return) and compares vendor paper against your preferred language.
1. Upload the contract to the vendor's Documents, setting the document type manually for MSAs, SOWs, and order forms.
2. Open the Contracts module to review extracted terms and the clause inventory. You can also ask in natural language: "what does this agreement say about insurance?" queries across all of the vendor's agreements at once.
3. Run a clause review against your organization's clause sets. The output shows deltas from your acceptable, fallback, and unacceptable tiers, by severity. Each clause that needs a decision comes with a suggested redline against your playbook, and when the agreement is a Word file the review can produce a redlined copy.
4. Triage each flagged clause: no action, accepted risk, false positive, or create a finding. Triaging is the review, and it clears the flag list.
5. Generate follow-up drafts for negotiation points, export the review to Excel, or assign it to legal in-platform.
<CardGroup>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
The full walkthrough: building clause sets from the library or your own paper, writing risk-tier variants, and working a review end to end.
</Card>
<Card title="Document Insights guide" icon="file-magnifying-glass" href="/user-guides/document-insights">
Defining the fields pulled out of every document, with a starter library and guidance on Extract vs Synthesize.
</Card>
</CardGroup>
<Frame>
<img alt="Contract overview with extracted terms and AI summary" />
</Frame>
<Frame>
<img alt="Clause review of a single clause with its analysis and the highlighted source language" />
</Frame>
<Frame>
<img alt="Clause review showing deltas from preferred language" />
</Frame>
<Note>
Contract findings can fold into assessment reports, for example an FFIEC control set applied to the contract, unified through a custom report template. Supersession is tracked too, so the record reflects what is currently in force.
</Note>
***
## Step 8: Work Radar signals
Radar watches external sources for events touching your third and fourth parties, and turns each one your organization is exposed to into a signal. Your job is to decide which signals become work, and to keep the rest out of the program.
1. Open **Radar**. The **Signals** tab opens on **All Signals**; switch to the **In Alert** view for the signals in alert and awaiting review. Each signal shows the highest severity any detector assigned, the vendors involved, the detectors that fired, and when it was last alerted. One event is one signal, however many detectors hit it.
2. Open a signal. The status card shows where it stands on the path from **Open** through **Tracked** and **In alert** to **Closed**, and the **Vendors** card lists which of your vendors were exposed, with **View full exposure** for the rest. The summary says what happened, and the timeline under it shows when it happened and when you were alerted. The **Detectors** tab lists each detector that fired, with its reasoning and confidence, **Exposure** lists every exposed vendor and why it matched, **Sources** holds the articles and advisories behind it, and **Timeline** shows the order things happened.
3. Act on it from the **Actions** menu. **Open case** for anything that needs investigation or vendor outreach (a case is preliminary, not yet a confirmed problem). **New finding** when it is confirmed, with an owner and a due date. **Start reassessment** when the vendor's risk picture has changed enough to re-run the plan. **Acknowledge** when you have seen it and nothing more is needed beyond a risk update: the signal is marked Triaged and Radar updates the vendor's risk. **Dismiss** when no action is needed at all. If the signal is irrelevant, dismissing also lets you teach your detectors not to alert on events like it.
4. Work the case. Send a vendor inquiry if you need their confirmation or remediation plan. Close it if the vendor is unaffected, or promote it to a finding once confirmed.
5. Check the risk update. When the detectors that fired are set to update risk, acknowledging the signal, creating a finding, starting a reassessment, or closing a case as **Resolved** or **Won't fix** raises the affected vendors' residual risk. **Review vendor risk profile updates** opens with the new numbers. Adjust any of them, then **Save and continue**, or **Continue** to accept. Dismissing never moves risk, and neither does closing a case as **False positive**. How the size of the move is decided is on the [Supplier Radar page](/products/supplier-radar#risk-propagation).
6. Dismiss what does not matter. Tick **Also dismiss future similar alerts** and the detectors that fired learn from it, so the next event like it stays quiet.
7. If a detector keeps firing on non-actionable items, say so. Detector guidance and severity thresholds are quick admin fixes.
No detector has fired on a **Tracked** signal. A vendor you depend on is linked to the event, so Radar shows the exposure and waits. It becomes work only when a detector fires or you act on it.
<Frame>
<img alt="Radar Signals tab listing signals with status, severity, vendors, and detectors" />
</Frame>
<Frame>
<img alt="Radar signal page showing the status card, generated summary, and the detectors that fired" />
</Frame>
<Frame>
<img alt="Radar cases tab" />
</Frame>
***
## Step 9: Obligations at a glance
Alongside what you require of vendors, Coverbase extracts what vendors require of you: CUECs pulled verbatim from SOC reports, and shared responsibilities from contracts and terms.
As a reviewer, you validate extractions against source language, assign owners and due dates, and send attestation requests to business stakeholders through a trimmed-down portal.
<Frame>
<img alt="Obligations overview" />
</Frame>
<Note>
The full obligations workflow (validation, ownership, and business-unit acknowledgement) is in the [Obligations guide](/user-guides/obligations).
</Note>
***
## Frequently asked questions
<AccordionGroup>
<Accordion title="How long does analysis take?">
Roughly 5 to 10 minutes for a typical assessment once evidence is collected, and 20 to 30 minutes when the document set is large. A long SOC 2 report takes considerably longer to read than a certificate of insurance. Very large control sets run longer still, and a full SIG core is around 300 questions. You do not need to keep the tab open. Issue counts drop over time as guidance is tuned, and the first-pass reduction is typically around 80% versus reviewing every control by hand.
</Accordion>
<Accordion title="Will the same assessment give identical results twice?">
Not exactly. AI models are non-deterministic, so two runs can differ slightly at the margins. Extraction is tuned to over-surface rather than miss. Specific control guidance narrows the variance, and results are stable on well-tuned sets.
</Accordion>
<Accordion title="I assessed a service and the vendor's score didn't move. Why?">
The score landed on the service. An assessment writes its residual risk to whatever it was scoped to, so a service-scoped assessment leaves the vendor's score alone unless your organization has **Risk Roll-up** turned on. With it on, the vendor takes the highest score among its live services. See [Where a vendor's score comes from](/user-guides/running-an-assessment#where-a-vendors-score-comes-from).
</Accordion>
<Accordion title="What if the AI is wrong?">
That is what review is for. Every result carries citations to source language, so errors are visible fast. Use Correct the AI to fix it permanently rather than dismissing it.
</Accordion>
<Accordion title="Do vendors respond to the portal?">
A bare portal invite lands around 50%. Contextualized follow-ups, the pre-signed MNDA, and automatic reminder cadences push that meaningfully higher, and the automated collection paths mean many vendors never need to be asked at all.
</Accordion>
<Accordion title="Where do Coverbase Library documents come from, and do ours go into it?">
Coverbase collects them itself: our agent requests documentation directly from the vendor and retrieves what the vendor publishes on its trust center, and a Coverbase reviewer approves each one before it appears. We do not scrape arbitrary web sources, because that material tends to be outdated and low quality. Nothing your organization uploads, and nothing a vendor sends you through the portal, is ever added to the library. See [Document library](/products/document-library).
</Accordion>
<Accordion title="Can Coverbase get documents from gated trust centers?">
It downloads anything ungated automatically and form-fills access requests for gated documents. It does not log into credentialed portals or read your inbox, so documents that arrive by email get uploaded manually.
</Accordion>
<Accordion title="What file formats work best?">
PDF. Citations and evidence highlighting are strongest there. DOCX is supported for extraction, and for web-based terms, download them and upload for parsing.
</Accordion>
</AccordionGroup>
***
## Ready to go?
Pick a vendor you know well, launch an assessment, and judge the results against a document set you already know well. That is the fastest way to build trust in the output.
<CardGroup>
<Card title="How to run an assessment" icon="list-check" href="/user-guides/running-an-assessment">
The screen-by-screen walkthrough of one assessment, intake to export.
</Card>
<Card title="Assessment quick reference" icon="bolt" href="/user-guides/assessment-quick-reference">
A one-page cheat sheet to keep open while you work.
</Card>
<Card title="Admin and setup guide" icon="sliders" href="/user-guides/admin-setup">
How the environment behind these workflows is configured.
</Card>
</CardGroup>
<Card title="Need help?" icon="envelope" href="mailto:support@coverbase.ai">
Email [support@coverbase.ai](mailto:support@coverbase.ai), or ask your Coverbase contact to run a live working session with your team.
</Card>
# Assessment quick reference
Source: https://docs.coverbase.com/user-guides/assessment-quick-reference
A one-page cheat sheet for running a vendor risk assessment in Coverbase: five steps, tips, common scenarios, and troubleshooting.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This quick reference is part of the [User Guides](/user-guides/overview) collection. Keep it open in a tab while you work. For the screen-by-screen walkthrough, see [How to run an assessment](/user-guides/running-an-assessment). For the wider daily loop, see the [Analyst and reviewer guide](/user-guides/analyst-reviewer). To pull assessment data into your own dashboard instead of exporting it, see [Replacing the assessment export](/mcp/assessment-exports).
</Info>
## Creating and running an assessment
<Steps>
<Step title="Initiate the assessment">
Go to **Assessments → + New Assessment**, add the vendor (add several to start a batch), and pick the **Assessment Plan**. The plan carries the control sets and questionnaires, so that single choice is most of the setup. Check the summary under the dropdown before you continue, and do not leave it on **None**. Your organization's default plan, if it has one, is preselected.
</Step>
<Step title="Get the evidence in">
On the **Documents** tab, five routes combine freely: existing vendor docs, request from vendor (portal), request automatic collection, the Coverbase Library, and the vendor's trust center. Once documents are in, click **Start Assessment** in the left panel; a vendor submitting the portal starts it for you. Analysis runs 20 to 30 minutes on a heavy document set. The left panel tracks the stages: Collecting Documents, Analyzing Controls, Review Results, plus any your organization has added.
</Step>
<Step title="Review the findings">
You see passes (control met with evidence) and issues (gaps that need your review). Validate the AI's findings and review the flagged issues. Every result cites the source document and page, with the passage highlighted.
</Step>
<Step title="Address each issue">
Review the evidence the AI found, then accept its assessment or override with your judgment. Use **Correct the AI** to adjust the guidance and rerun a wrong result, and **Preserve** to pin a result against future runs. Select rows for bulk **Resolve** (mitigated or accept risk), **Add Finding**, or **Create follow-ups**. Add notes for the audit trail.
</Step>
<Step title="Generate follow-up questions">
If needed, click **Draft follow-up** on a result, or select rows and **Create follow-ups**. The AI writes targeted questions for only the gaps. Saving creates a draft; the vendor sees nothing until the batch goes out through the portal. Only the followed-up controls, and any that depend on their answers, are reanalyzed when they respond.
</Step>
<Step title="Final review and approval">
Domain reviewers sign off (residual risk reads "Not set" until they do), then **Complete Assessment**: action, vendor status, next reassessment date, and recommendation. Export as PDF, Excel, or CSV, or as Word if your organization uses a custom report template.
</Step>
</Steps>
## Quick tips
<CardGroup>
<Card title="The AI does most of the work" icon="robot">
It searches vendor websites, trust centers, and docs, pulls integrated data, and analyzes uploaded documents like SOC 2 reports and contracts.
</Card>
<Card title="You focus on judgment calls" icon="scale-balanced">
Validate the AI's findings, review flagged issues, and override when the AI is wrong.
</Card>
<Card title="Speed matters" icon="gauge-high">
Do not re-read what the AI already found. Focus on the yellow and red flags, and use bulk actions for similar issues.
</Card>
</CardGroup>
<Tip>
Spend your time on the flagged gaps rather than re-reading what the AI already found.
</Tip>
## Common scenarios
<AccordionGroup>
<Accordion title="Vendor has comprehensive security docs (ISO, SOC 2, etc.)" icon="file-shield">
Upload the documents during the assessment. The AI extracts the relevant controls, and most technical controls auto-pass based on the report, with exceptions flagged. You review any gaps.
Typical time: 15 to 20 minutes.
</Accordion>
<Accordion title="Small vendor, limited docs" icon="file-circle-question">
The AI searches public info, so more issues get flagged because there is less evidence. Generate a targeted questionnaire and let the vendor complete it through the portal.
Typical time: 30 to 45 minutes, plus vendor response time.
</Accordion>
</AccordionGroup>
## Troubleshooting
| Problem | Solution |
| - | - |
| AI missed obvious evidence | Upload the document, then use **Rerun** from the assessment **Actions** menu |
| Too many questions generated | Review the control-set mapping, it may be too broad |
| Vendor cannot access the portal | Check email spam and resend the invitation |
| Wrong control set applied | Check the plan the assessment came from (the **Plan** card in the left panel), then the vendor's tags on the vendor profile |
| Assessment stuck in **Collecting Documents** | Check whether the vendor portal is still open. If you already hold the documents, attach them and click **Start Assessment** |
| Assessment has no controls attached | The plan was left on **None**. Pick a plan, or rerun with one |
| **Complete Assessment** is grayed out | The assessment has not reached **Review Results**, or an analysis run is still in progress. Hover it: if it says only risk analysts can complete, your organization restricts completion to the vendor's risk analysts and admins |
| Residual risk reads "Not set" | That domain has not been reviewed yet. Someone needs to **Start review** |
| **Retrieve from Trust Center** is not offered | The vendor record has no Trust Center URL. Add it on the vendor, then retry |
| Assessments list looks empty | Clear the filters or switch back to **All assessments**. Filters persist between visits |
| "Unable to identify intake portal" | Use your organization's intake link, found under **Intake → Request new vendor** |
| Vendor wants to work in a spreadsheet | Once follow-ups are sent, use **Download workbook** and **Import responses** in the follow-up bar's actions menu on the Issues tab |
| "Where did the Coverbase Library documents come from?" | Coverbase collected them from the vendor and their trust center. Nothing you upload goes in. See [Document library](/products/document-library) |
| Changed the plan and need everything re-scored | A follow-up only reanalyzes affected controls. Use **Rerun** from the assessment **Actions** menu |
## Control frameworks at a glance
| Framework | What it covers |
| - | - |
| NIST CSF | Broad information security baseline |
| SIG Lite | Standardized vendor questionnaire |
| SOC 2 | Service organization controls |
| ISO 27001 | International security standard |
| GDPR | EU data protection |
| PCI DSS | Payment card security |
| DORA | EU financial services resilience |
<Note>
Your organization may have custom frameworks. Check **Configuration → Controls**.
</Note>
## Need help?
<CardGroup>
<Card title="Platform support" icon="envelope" href="mailto:support@coverbase.ai">
[support@coverbase.ai](mailto:support@coverbase.ai)
</Card>
<Card title="Full walkthrough" icon="list-check" href="/user-guides/running-an-assessment">
How to run an assessment, screen by screen.
</Card>
<Card title="The daily loop" icon="user-check" href="/user-guides/analyst-reviewer">
The complete Analyst and reviewer guide.
</Card>
</CardGroup>
# Assignment, delegation and out of office
Source: https://docs.coverbase.com/user-guides/assignment-and-delegation
How work reaches a person in Coverbase: user groups, round-robin and assign-to-all routing, out-of-office windows that skip a member automatically, reassignment, and the assignment log that attributes every hand-off.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is for admins who own routing. For what the work itself is, see [Reviews, approvals and gates](/user-guides/reviews-and-approvals). For what a person is allowed to do once it reaches them, see [Permissions and roles](/user-guides/permissions-and-roles).
</Info>
A gate assigned to one person stops when that person is on leave. Coverbase can route work to a **user group** rather than a named individual, so it survives someone's holiday. It records both the group that was asked and the individual who ended up accountable.
## User groups
A user group is an org-scoped set of people with shared routing rules, managed under **Configuration → Organization → User groups** (create one with **New User Group**). Anywhere Coverbase accepts an assignee, it accepts a group: review gates, work queue items, questionnaire submission reviewers, risk domain reviewers, findings, follow-ups, watchers, and `@`-mentions in notes.
Each group carries:
| Setting | What it does |
| - | - |
| **Assignment strategy** | `Assign to all` or `Round robin`. See below. |
| **Group lead** | The named point of contact, badged in the member list. |
| **Members** | Each with an `Active` / `Inactive` status, a place in the rotation, and an optional out-of-office window. |
### Two strategies
<CardGroup>
<Card title="Assign to all" icon="users">
The item is added to **every** eligible member's work queue and everyone is notified. The group is collectively accountable and there is no single individual assignee. Use it for a committee, or for a queue where whoever is free picks it up.
</Card>
<Card title="Round robin" icon="rotate">
**One** member is picked from the rotation at assignment time. Both the group and that person are recorded, so the work has an individual owner while the record still shows it was handed to the team. Use it for balanced case load across a review desk.
</Card>
</CardGroup>
The rotation is deterministic and ordered, so the next assignee is predictable rather than random, and the interface can show who is up next before an assignment is made.
## Out of office
Each member of a group has an **Out of office** window: a **From** date and a **To** date, set from the member row. Coverbase enforces it at routing time.
<Steps>
<Step title="Set the window">
On the group's member list, choose **Set out of office** and pick the dates. Members can also be marked `Inactive` indefinitely, which is the same thing without an end date, for a leave of absence or a secondment.
</Step>
<Step title="Routing skips them automatically">
Anyone inside their window is excluded from the eligible set before the strategy runs. A round-robin rotation steps over them to the next available member rather than parking work in an empty inbox; an assign-to-all group notifies everyone except them.
</Step>
<Step title="They return without an admin touching anything">
The window expires on its own. No one has to re-enable the member when they return.
</Step>
<Step title="Nothing is silently dropped">
If every member of a group is out or inactive, the routing outcome is recorded as `no eligible members` rather than passing quietly. That is a visible state you can alert on, not an assignment that never happened.
</Step>
</Steps>
<Warning>
Out of office governs **new** assignments. Work already sitting on someone's queue when their window opens stays there. Move it with the reassignment step below, or route the queue to a group so the next round lands on someone present.
</Warning>
## Delegation and reassignment
Coverbase treats delegation as an explicit, attributed hand-off rather than an impersonation.
* **Reassign in place.** Every group carries an **Assignments** tab listing the open work across its members, with filters for member, item type and status, and a **Reassign to** action. Reassigning cancels the previous holder's pending item rather than completing it, because they never did the work, and mints a fresh one for the new holder. The completed / canceled distinction keeps throughput reporting accurate.
* **Reassign a single gate.** A review's or a submission's reviewer picker takes an individual, a group, or nothing. A group assignment is re-resolved against **current** membership when the work arrives, not against the roster as it stood when the item was first sent. A personnel change between send and response therefore routes to the person who is there now.
* **Escalate to the lead.** The group lead is a named, queryable field, which gives a workflow somewhere to send an item that has aged past its target.
* **Nobody inherits authority.** Delegation moves the item, never the permission. A delegate acts under their own role, and the decision is recorded under their own name. See [Permissions and roles](/user-guides/permissions-and-roles).
## The assignment log
Every group-driven routing decision writes its own log row, independent of the object it acted on. Each row records:
| Field | Example |
| - | - |
| Group | Financial Crime Review |
| Trigger | Assignee, watcher, or mention |
| Strategy applied | Round robin, as configured at that moment |
| Outcome | Assigned round robin / assigned all / no eligible members |
| Assigned to | The individual picked, for round robin |
| Notified | Every member notified, for assign to all |
| Triggered by | The person or workflow that caused it |
| Target | The object it happened on, and when |
It answers "who was supposed to approve this, and why did it land on them" months later. It survives a member leaving the group, and it records the strategy that was in force at the time rather than the one configured today.
Group routing decisions also surface in the [organization audit trail](/security/audit-trails) alongside the object changes they caused.
## A worked pattern
A common financial-services arrangement:
1. **Second-line reviews** route to a `Risk Committee` group on **Assign to all**, because the whole committee is meant to see the item.
2. **Domain SME reviews** route to per-domain groups (`InfoSec Review`, `Financial Crime`, `Legal`, `Privacy`) on **Round robin**, so each domain has one accountable person per assessment and the load spreads across the desk.
3. **Every SME sets their own out-of-office window** at the start of leave. The rotation steps over them for the duration, with no admin ticket and no gate waiting on an empty desk.
4. **The `no eligible members` outcome is alerted on**, so a domain that is entirely out during a holiday period surfaces as an operational problem rather than as a quiet backlog.
## Related
<CardGroup>
<Card title="Reviews, approvals and gates" icon="gavel" href="/user-guides/reviews-and-approvals">
Gate outcomes, parallel domain reviews, multi-approver logic and rework loops.
</Card>
<Card title="Permissions and roles" icon="lock-keyhole" href="/user-guides/permissions-and-roles">
What a delegate is allowed to do once the work reaches them.
</Card>
<Card title="Email notifications" icon="envelope" href="/user-guides/email-notifications">
What each assignment and reminder sends, and how to tune it.
</Card>
<Card title="Audit trails" icon="list-timeline" href="/security/audit-trails">
Where routing decisions land in the organization-wide record.
</Card>
</CardGroup>
# Generate a clause set from your own contract
Source: https://docs.coverbase.com/user-guides/baseline-contract-extraction
Upload your template MSA or DPA and let Coverbase extract a clause set from it: what it pulls out, why it drops language it cannot quote, and what you must add before the set is usable.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This page is part of the [User Guides](/user-guides/overview) collection and goes with the [Contract Guardian guide](/user-guides/contract-guardian), which covers clause sets end to end. Read this one when your standard is a document rather than a spreadsheet.
</Info>
Most companies already have their standard written down as a contract: the MSA you send first, the DPA your privacy team maintains, the security addendum you attach to anything touching customer data. **Import from Document** reads one of those and turns it into a clause set, so your playbook starts from language you already use rather than a blank page. The same entry reads a clause library or negotiation playbook; see [Importing a clause library or playbook](#importing-a-clause-library-or-playbook).
<Note>
This is one of four ways to build a clause set. The others are copying the packaged library, [importing a spreadsheet](/user-guides/clause-set-spreadsheet-import), and adding clauses by hand. They mix freely: generate from your paper, then paste in the two clauses your template forgot.
</Note>
## Which import do I want?
The two upload paths solve different problems.
<CardGroup>
<Card title="Import from Document" icon="wand-magic-sparkles">
**You have a contract.** Coverbase reads the document and proposes the clauses, with the exact source text quoted. Fastest way from "we have a template" to a working set, but every clause arrives with one tier, so you finish the tiering by hand.
</Card>
<Card title="Import from Spreadsheet" icon="file-import" href="/user-guides/clause-set-spreadsheet-import">
**You have a playbook.** Your standards already exist as structured rows, probably with fallback positions. You get exactly what you typed, including full multi-tier variant language, and nothing is inferred.
</Card>
</CardGroup>
A common sequence: generate from your paper to get the clause inventory, then hand-write the fallback tiers in the UI. If your team already maintains a negotiation matrix, skip extraction and import the spreadsheet.
## Run an extraction
<Steps>
<Step title="Upload the baseline">
On **Configuration → Clause Sets**, open **Add Clause Set** and choose **Import from Document**. Drop in your template as a PDF, DOCX, DOC, TXT, or MD file.
Set **Document type** to **Baseline contract (one agreement)**, or leave it on **Detect automatically**. Give the set a **Name**, and optionally a description, then choose **Import**.
Use a **clean template**, not an executed agreement. A signed contract carries one counterparty's negotiated edits, and you would be baking their redlines into your standard.
</Step>
<Step title="Wait for processing">
Extraction runs in the background; you can leave the page and come back. The clause set appears immediately with a processing indicator and fills in as the run completes.
</Step>
<Step title="Review what it extracted">
Each proposed clause arrives with a name, category, severity, applicable component types, and the **exact source text** it came from, with a page citation you can check against your document.
</Step>
<Step title="Add your fallback tiers">
This is the step people skip, and the set is not usable without it. See [What you have to finish](#what-you-have-to-finish) below.
</Step>
<Step title="Activate it">
Generated clause sets are created **inactive**, so a half-finished playbook cannot be run against a live contract: an inactive set is not offered when you start a review, and it carries an **Inactive** badge on the Clause Sets page. Once the tiers are in, open the set, click the actions menu beside **Add Clause** and choose **Activate**. **Deactivate** in the same menu takes it back out of use; reviews that already used it keep their results, but they cannot start a new round until you activate it again.
</Step>
</Steps>
## What you get back
Each extracted clause is a normal reference clause, so you can edit, retier, or archive any of it.
| Field | How it is filled |
| - | - |
| **Identifier** | Auto-assigned as `BASE-001`, `BASE-002`, ... Rename them to your own scheme if you have one. |
| **Name** | Proposed from the clause heading. |
| **Category** | Proposed from the clause subject. |
| **Severity** | Proposed from the clause subject. Check these: the model does not know which clauses would block *your* signature. |
| **Applicable component types** | Proposed from the document type it read. |
| **Rationale** and **Guidance** | Proposed where the text supports them: why the clause matters, and a short note on how to compare vendor language against it. |
| **Source evidence** | The exact quoted text plus its page, kept on the clause so a reviewer can trace any standard back to your template. |
| **Variants** | Exactly one: **Tier 1**, labeled **Preferred: baseline contract language**, your template's own language. |
<Note>
**Language it cannot quote verbatim is dropped, not paraphrased.** Every extracted clause and every piece of source evidence is checked back against the text of the document it cites; anything that does not appear there contiguously is discarded. You may get fewer clauses than you expected, but what you get is your own paper, not a model's summary of it.
</Note>
## What you have to finish
<Warning>
**A single Tier 1 variant is a floor, not a playbook.** It marks anything that is not your exact template language as needing review, which on a real vendor's paper is almost everything. A set run in that state flags nearly every clause.
</Warning>
Before you point a generated set at a live contract:
1. **Add the tiers you would accept.** For each clause that matters, write the Tier 2 ("acceptable") and Tier 3 ("fallback") language your legal team would sign without escalating.
2. **Fill in the Guidance field.** Extraction may propose a short comparison note, but not the aliases and extraction signals that help the matcher find a clause under a different heading. The [Contract Guardian guide](/user-guides/contract-guardian) shows the four-section format.
3. **Retune severities.** Reserve Critical for clauses that would block a signature.
4. **Archive what you do not care about.** A template contains boilerplate you have no opinion on. Every clause you keep is a clause every review has to triage.
5. **Activate it** from the set's actions menu, then test it against a contract you already know before you rely on it.
## Importing a clause library or playbook
Some teams keep their standard as a clause library or negotiation playbook rather than a contract: numbered clauses, each with a preferred position, a fallback, and sometimes a line the team will not cross. **Import from Document** reads that layout as it is written instead of guessing at it. Choose **Clause library / playbook (positions per clause)** under **Document type**, or leave **Detect automatically** on.
| In the document | In the clause set |
| - | - |
| Each numbered clause | One reference clause, in the document's order |
| The clause number | The identifier, under the **ID prefix** you set (for example `PB-01`). Left blank, the prefix is the set name's initials. |
| The preferred position | Tier 1 |
| The fallback position | Tier 3 |
| A "do not accept" position, or a clause on the document's "no fallback" list | Tier 5 |
| Negotiation notes, approval routing, and the rules around each clause | The clause's guidance |
| The document's purpose and legend | The set's description, when you leave **Description** blank |
The positions are copied verbatim, never rewritten. Severity is set from the document's own rules and the clause's subject: **Critical** for a clause on the document's "no fallback" list or one whose deviations need executive approval, **High** for one with a floor or a subject such as data, security, or indemnity, **Low** for administrative terms such as notices and governing law, and **Medium** otherwise. Check them as you would any proposed severity.
When the run finishes, the clause set says how many of the document's clauses it imported. Anything the reader could not place, such as a clause with no preferred position or text outside any labeled block, is listed above the clauses under **items need review**. Open those clauses and confirm or fix them.
An imported playbook is created inactive like any other generated set. Under the default scoring, a vendor whose language matches your fallback reads as **Needs review**.
## Troubleshooting
| What you see | What it means |
| - | - |
| Extraction returned far fewer clauses than the document has | Expected on documents where the text layer is poor. Language that cannot be quoted verbatim is dropped rather than guessed at. Check the PDF is text-based, not a scan of a printout. |
| The clause set is stuck processing | Extraction runs in the background and larger documents take longer. If it stays pending well beyond a few minutes, the run failed. The clause set surfaces the failure, and you can archive it and retry. |
| Clauses came back with your counterparty's edits | You uploaded an executed agreement instead of your template. Start again from clean paper. |
| Everything is marked as a deviation on the first review | The set still has one tier per clause. Add fallback tiers before running it against a live contract. |
| The clause set is not offered when you start a review | Generated sets start inactive, and only active sets are offered. Open the set and choose **Activate** from the actions menu beside **Add Clause** once the tiers are in. |
| A playbook import says fewer clauses were imported than the document has | Open the list under **items need review** on the clause set. It names what the reader could not place. |
## Related
<CardGroup>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
Clause sets end to end: the reference clause anatomy, writing risk-tier variants, and running a review.
</Card>
<Card title="The clause set library" icon="book-open" href="/user-guides/clause-set-library">
The 12 packaged clause standards you can copy instead of, or alongside, extracting your own.
</Card>
<Card title="Import and export clause sets as spreadsheets" icon="file-import" href="/user-guides/clause-set-spreadsheet-import">
Bring a playbook in from a workbook when your standards already live in structured rows.
</Card>
</CardGroup>
# Bills of materials
Source: https://docs.coverbase.com/user-guides/bill-of-materials
How to upload a vendor's SBOM, read its components, keep the right version applied, and get a Radar alert when a known exploited vulnerability affects a component it lists.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For the rest of the vendor page, see [The vendor record](/user-guides/vendor-record). For how Radar signals are worked once they arrive, see [Working Radar signals](/user-guides/radar-signals).
</Info>
A bill of materials (BOM) is a vendor's machine-readable list of what its product is built from: libraries, frameworks, containers, firmware, models. Upload one to a vendor and Coverbase breaks it into searchable components. Radar then checks those components against known exploited vulnerabilities and raises an alert on the vendor when one applies.
The most common mistake is expecting alerts from a file that was never read. Coverbase reads bills of materials in JSON only, and Radar only checks files typed **SBOM**. Check the format, type and status badges after every upload.
## Before you start
You need:
* The vendor's bill of materials as **CycloneDX JSON** or **SPDX JSON**. Ask the vendor for JSON if they send another encoding. See [Supported formats](#supported-formats).
* A file no larger than 100 MB.
To get Radar alerts from it, you also need:
* Radar turned on for your organization.
* The **NIST National Vulnerability Database (with KEV)** source connected. The recommended **Exploited Vulnerabilities & Supply Chain Compromise** detector adds it when enabled, so most organizations already have it. Otherwise add it under **Configuration → Radar → Sources → Add source → From Source Library**. See [Sources](/user-guides/radar-signals#sources).
* The vendor in **Active** status and linked to a company record. A vendor you created by picking it from the directory is already linked.
## Uploading a bill of materials
1. Open the vendor and choose the **Bill of Materials** tab. To attach the file to one service instead, open that service's page and use its **Bill of Materials** tab.
2. Drag the file onto **Upload a CycloneDX or SPDX JSON bill of materials**, or click it to browse. One file at a time.
3. Wait for the toast: *Uploaded "file name". Parsing has started.*
Parsing runs in the background and usually takes seconds. Large SBOMs can take a few minutes. The file also appears on the vendor's **Documents** tab, so it travels with the rest of the vendor's evidence.
<Note>
Upload bills of materials on the **Bill of Materials** tab. A CycloneDX or SPDX file uploaded through the **Documents** tab may be classified as an SBOM, but it does not appear on the **Bill of Materials** tab and Radar does not read it. To fix one that was uploaded there, edit the document and set its document type to a bill of materials type (for example **SBOM (CycloneDX)**). It is then parsed like any other upload.
</Note>
Suppliers cannot upload a bill of materials through the supplier portal. A file a supplier sends you has to be uploaded here by someone on your team.
## Supported formats
Coverbase supports **CycloneDX JSON** and **SPDX JSON**, in files ending `.json` or `.cdx`.
CycloneDX XML and SPDX tag-value files are not supported, and the upload box refuses them. If a vendor sends one, ask them for a JSON export, or convert it yourself with the CycloneDX or SPDX command-line tools.
Coverbase reads each component's name, version, type, package URL (purl), CPE, supplier, licenses and hashes. It does not read the dependency graph between components.
## Reading the current bill of materials
**Current bill of materials** shows the file Coverbase treats as this vendor's inventory. Its header carries three badges and a count:
* **Format**: **CycloneDX** or **SPDX**, or **Unknown format** when the file was neither.
* **Type**: **SBOM**, **AI-BOM**, **Hardware BOM** or **SaaS BOM**. See [How the type is decided](#how-the-type-is-decided), because only **SBOM** is checked by Radar.
* **Status**: **Pending** and **Parsing** while it works, then **Parsed**, **Failed** or **Unsupported**.
* **Unique components**: identical entries listed more than once in the file are counted once.
**Download** returns the original file.
Once the status is **Parsed**, the components table lists **Name**, **Version**, **Type**, **Licenses**, **Vendor** (the component's supplier as the file states it) and **Package URL**. **Search components** matches the name, package URL or group. **Filter by component type** narrows to one type.
When the status is **Failed** or **Unsupported**, the panel shows *We could not parse this bill of materials.* or *This bill of materials format is not supported.* with the reason underneath. The file is kept either way.
### How the type is decided
SPDX files are always **SBOM**. For CycloneDX, Coverbase reads the component types in the file and picks the first that applies:
1. **AI-BOM** if any component is a machine learning model.
2. **Hardware BOM** if any component is a device, firmware or operating system.
3. **SaaS BOM** if the file describes a platform or service.
4. **SBOM** otherwise.
<Warning>
A software SBOM that lists an **operating system** component, such as the base image of a container, is typed **Hardware BOM**. Radar only checks files typed **SBOM**, so that vendor gets no vulnerability alerts. If the type badge is wrong for your file, ask the vendor for an SBOM without the operating system entry, or tell Coverbase support.
</Warning>
## Keeping the right version applied
Each upload adds a row to **Upload history**, newest first, with **File name**, **Format**, **Type**, **Status**, **Components** and **Uploaded**. One row is badged **Applied**; the rest are **Historical**.
* **The newest upload is applied automatically.** Uploading a newer SBOM replaces the old one as the vendor's inventory. You do not need to remove the old file.
* **Set as current** makes an older upload the applied one again. It appears only on rows that parsed successfully, and it is recorded in the vendor's activity log.
* **A newer upload that failed still shows as Applied** on this tab. Radar ignores it and keeps using the newest upload that is a **Parsed SBOM**. Fix the file and upload it again, or use **Set as current** on the last good one so the tab matches what Radar uses.
Click a row to open that upload's components.
### Vendor and service bills of materials
A bill of materials uploaded from a service page belongs to that service and to its vendor. The service's tab shows the newest upload for that service. The vendor's tab shows the newest upload across the vendor and all of its services.
<Note>
Radar reads one bill of materials per vendor: the newest parsed SBOM across the vendor and its services. If a vendor has several products, each with its own SBOM, only the most recently uploaded one is checked. Combine them into one file if you need all of them checked.
</Note>
## How Radar uses a bill of materials
When Radar collects a CVE record from the National Vulnerability Database, it compares the products and version ranges the CVE affects against the components in each vendor's applied SBOM. A component that matches raises an alert on that vendor.
### Which vulnerabilities are checked
The **NIST National Vulnerability Database (with KEV)** source only collects vulnerabilities on the CISA Known Exploited Vulnerabilities (KEV) catalog. An SBOM alert therefore always means a component with a flaw attackers are known to be exploiting, not every CVE that mentions one of the vendor's libraries.
A CVE is checked when Radar collects its record, which happens when the CVE is added to the KEV catalog or its NVD record changes. **Uploading an SBOM does not rescan the vulnerabilities Radar already holds.** A new SBOM is checked against each CVE the next time that CVE's record is collected.
### How a component is matched
Coverbase compares each vulnerable product NVD lists against the component's CPE first, then its package URL, then its name. npm and PyPI packages are matched on their exact package name. Everything else is matched on the vendor and product words.
Then it checks the version against the affected range.
* A version inside the range matches.
* A version outside it does not.
* A component **without a version** only matches a vulnerability that affects every version. Otherwise it is skipped, and no alert is raised.
* A version Coverbase cannot compare, such as a build label, is also skipped.
Radar raises an alert only when the match is certain. An SBOM with complete versions and package URLs gets the most accurate results.
### What you see
A match raises an alert from the **SBOM Vulnerability Alerts** detector. Every organization has this detector. It is managed by Coverbase, applies to all your vendors, and does not appear in your detector list, so there is nothing to configure or enable.
* **Severity** follows the CVE's CVSS score: **High** at 7.0 and above, **Medium** at 4.0 and above, **Low** below that, and **Informational** when NVD gives no score. There is no separate critical level.
* **The summary** reads *CVE-ID affects component version in vendor's SBOM*, and the reasoning lists every matched component and how it matched.
* **The signal** lands in **Radar → Signals** like any other, and is triaged the same way. See [Triaging a signal](/user-guides/radar-signals#triaging-a-signal).
On the signal's **Exposure** tab, the vendor appears as a **Direct** exposure with a **Source** column naming the matched components. In the **Flow** view, click a component for **Why This Matched**: the component's package URL and CPE, whether it matched by CPE, PURL or component name, the NVD criteria it matched, and **View uploaded bill of materials**.
### Your bill of materials stays private
CVE events are shared across Coverbase customers. SBOM matches are not. The exposure and the alert belong to your organization only, and another customer looking at the same CVE never sees your vendor, its components, or that a match happened. Vendors often share SBOMs under NDA, and nothing in the file leaves your workspace.
### Replacing or withdrawing an SBOM
A newer upload changes what future CVEs are checked against. It does not withdraw alerts already raised from the older file. Dismiss those on the signal if the new SBOM no longer contains the component.
Only files typed **SBOM** are checked. **AI-BOM**, **Hardware BOM** and **SaaS BOM** files are stored and browsable, but they raise no alerts.
## Troubleshooting
| What you see | Usually means |
| - | - |
| *is not a JSON file* when you upload | The file is CycloneDX XML or SPDX tag-value. Export or convert it to JSON and upload that. |
| Status **Unsupported** | The file is JSON but not a CycloneDX or SPDX bill of materials. Ask the vendor for a CycloneDX or SPDX export. |
| Status **Failed** | The JSON is malformed or truncated. Read the reason in the panel, and ask the vendor for a fresh export. |
| Status stays **Pending** or **Parsing** for more than 15 minutes | Parsing stopped. Upload the file again. If it stalls a second time, contact support with the file name. |
| The file is on **Documents** but not on **Bill of Materials** | It was uploaded through **Documents**. Set its document type to a bill of materials type, or upload it again on the **Bill of Materials** tab. |
| Type shows **Hardware BOM** for a software product | The file lists an operating system component. See [How the type is decided](#how-the-type-is-decided). |
| No alerts, ever, for a vendor with an SBOM | Check, in order: the **NIST National Vulnerability Database (with KEV)** source is connected, the vendor is **Active** and linked to a company record, the applied file is a **Parsed SBOM**, and the components carry versions. |
| An alert you expected did not arrive after uploading | The CVE was collected before the upload. It is checked when its NVD record next changes. |
| An alert names a component the vendor no longer ships | The alert came from an earlier SBOM. Dismiss it on the signal. |
## Related
<CardGroup>
<Card title="Working Radar signals" icon="satellite-dish" href="/user-guides/radar-signals">
Triaging the signals an SBOM match raises.
</Card>
<Card title="The vendor record" icon="building" href="/user-guides/vendor-record">
The rest of the vendor page, including its documents and services.
</Card>
<Card title="Source library" icon="book" href="/products/source-library">
The NVD source and the other vulnerability feeds Radar can collect.
</Card>
<Card title="Bill of Materials API" icon="code" href="/api-reference/bill-of-materials">
Uploading and searching bills of materials from your own systems.
</Card>
</CardGroup>
# Black Kite monitoring guide
Source: https://docs.coverbase.com/user-guides/black-kite-monitoring
How to connect your Black Kite portfolio to Radar, choose which vendors are watched, and turn known exploited vulnerabilities and focus tags into alerts.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It assumes your organization already has a Black Kite subscription. For what Radar does generally, see [Supplier Radar](/products/supplier-radar).
</Info>
If you already pay Black Kite to rate your suppliers, this connects that rating work to the rest of your risk program. Coverbase sweeps your Black Kite portfolio on a schedule, matches each company back to the vendor record you already hold, and raises a Radar alert when a vendor you care about picks up an exploited vulnerability or an incident write-up.
Two things shape the choices on the setup page.
**Black Kite limits how fast anyone can read it.** Your Black Kite tenant is capped at 60 API requests a minute, and there is no single call that returns every finding in your portfolio. Findings are fetched one company at a time. The settings below are therefore not only a filter on what you see. They also decide how far Coverbase can get through your portfolio in a day, so narrowing the scope is what lets monitoring keep up.
**A source collects; a detector alerts.** These are two separate steps. Doing only the first is the usual reason nothing appears to happen, so the configuration page walks you through both.
## Before you start
You need:
* A Black Kite **client ID and client secret** with API access. Your Black Kite administrator generates these.
* Admin access to **Configuration → External Integrations**, with permission to update integrations.
* Vendors in Coverbase whose website matches the domain Black Kite monitors. That match is how a Black Kite company becomes one of your vendors, and it is exact, so read [how matching works](#how-black-kite-companies-become-your-vendors) before you start.
## Step 1. Connect your credentials
Go to **Configuration → External Integrations** and choose **Black Kite**.
Paste your client ID and client secret and click **Save Black Kite Configuration**. Then click **Test connection**, which makes one harmless call to Black Kite and confirms the credentials work. Do it now rather than finding out from a week of failed overnight runs.
<Frame>
<img alt="Black Kite configuration page showing API credentials and Radar monitoring settings" />
</Frame>
<Warning>
Your client secret is stored encrypted and is never shown again. If you lose it, generate a new one in Black Kite rather than trying to recover it here.
</Warning>
## Step 2. Choose what gets collected
Once credentials are saved, the **Radar monitoring** section below them becomes available. Until then it reads *Save your Black Kite credentials above to configure monitoring.*
Coverbase can collect two kinds of signal from Black Kite. Turn on either or both.
**Known exploited vulnerabilities.** CVEs from the CISA Known Exploited Vulnerabilities catalog that Black Kite found on a vendor's internet-facing infrastructure. "Known exploited" means attackers are using the flaw now, not that it is theoretically severe. These merge with the vulnerability intelligence Coverbase already collects from NVD and CISA, so you get one view of a CVE rather than two.
**Focus tags.** The incident write-ups Black Kite's research team attaches to a company, such as a reported ransomware attack, a data breach, or a supply-chain compromise. You get their headline and evidence, not only a label.
<Tip>
Leave the focus tag list empty to collect every tag. If you name specific tags, Black Kite's newly published ones are ignored until you come back and add them, and the newest tags are usually the ones about a campaign that is currently running.
</Tip>
<Frame>
<img alt="Black Kite monitoring settings with signal toggles and thresholds" />
</Frame>
## Step 3. Decide which vendors are watched
Spend the most time on this setting.
**Ransomware Susceptibility Index threshold.** Black Kite scores every company from 0 to 1 on how likely it is to suffer a ransomware attack. Set a threshold and Coverbase only looks closely at vendors above it. The default is 0.5. Turning this off means examining every vendor in scope, which uses considerably more of your daily request budget.
**Technical grades.** Optionally also examine vendors carrying particular Black Kite letter grades, regardless of their susceptibility score. Leave it empty to apply no grade rule.
**Vendor scope.** A filter over your own vendor records. Only vendors matching it are monitored at all.
This is where you encode your policy. A common shape is *inherent risk is significant or high*, **and** *the vendor handles regulated data*. Both are ordinary vendor filters:
* **Risk ranking** uses your own **Inherent risk level**, whatever you have named your levels.
* **Regulated data access** (PHI, PCI, SSN) uses a vendor field you control. If you do not already track this, create a multi-select custom field on vendors, for example *Regulated data* with options *PHI*, *PCI* and *SSN*, and populate it. Vendor tags work too. Either becomes filterable here immediately.
<Note>
Coverbase does not infer PHI or PCI access for you here. The data types recorded on a vendor's risk profile are extracted from assessment text as free-form wording, so "PHI", "Protected Health Information" and "PHI (HIPAA)" all appear as different values. That is precise enough to read, but not precise enough to decide who gets monitored. A field with a fixed option list is.
</Note>
**Vendors examined per run.** A ceiling on how many vendors get a detailed look in a single pass. The most ransomware-susceptible go first, and anything past the ceiling is picked up on the next run rather than dropped. Raise it if your portfolio is large and you would rather trade run time for coverage.
Click **Save monitoring settings**.
## How Black Kite companies become your vendors
Read this before you troubleshoot, because most "why is nothing happening" questions come down to matching.
The nightly run matches on **domain**. Black Kite reports a domain for each company it monitors, and Coverbase compares it against the **vendor's own website**, the website on the **company record** the vendor is linked to, and any **domains you have added by hand** (see below). Any one of them matching is enough, which helps when you have recorded the product domain and Black Kite monitors the corporate one.
Before comparing, both sides are tidied up the same way. Capitals are lowered, `https://` and any path are dropped, and a leading `www.` is removed.
Coverbase then tries three things in order, stopping at the first that works:
1. A **company already pinned** to the vendor by an on-demand check. This is the most reliable, because it is Black Kite's own company id rather than a string comparison.
2. An **exact host match**.
3. The Black Kite host's **parent domain**, walked one label at a time.
| Black Kite monitors | Your vendor's website | Match |
| - | - | - |
| `northwind.example` | `northwind.example` | Yes |
| `northwind.example` | `https://www.northwind.example/careers` | Yes |
| `mail.northwind.example` | `northwind.example` | Yes. The parent is tried after the exact host. |
| `northwind.example` | `app.northwind.example` | **No.** Step 3 only ever climbs, never descends. |
| `halden.example` | `haldenmedical.example` | **No.** A near-identical name is still a different domain. |
| `orbitline.example` | (no website recorded) | **No.** Nothing to compare. |
<Note>
Step 3 climbs but stops before the registrable domain, so `aws.amazon.com` never reaches a vendor recorded as `amazon.com`. Those are different suppliers, as are Opsgenie and Atlassian.
</Note>
<Warning>
A vendor with no website recorded can never match, no matter how it is scoped or which detector is watching. If you are testing this and seeing nothing, check the website field first.
</Warning>
Two more things follow from matching this way:
* **Matching only ever climbs.** Coverbase would rather miss a match than quietly file one supplier's exploited vulnerability under another.
* **If two vendors share a domain, only one of them gets the findings.** Which one is stable between runs, but it is arbitrary. That is a sign of a duplicate vendor record to merge, not something to configure around.
For alerts to attribute correctly, a vendor should also be linked to a company record, which happens on its own when you create the vendor by picking it from the directory rather than typing a bare name. Exploited vulnerabilities are recorded against the CVE, so one CVE can affect several of your vendors at once. The company link is how Coverbase keeps each vendor's alert to that vendor's own findings.
## Fixing a vendor that will not match
Every vendor page carries a **Black Kite** card in its Radar section, in both the current and the previous vendor layout. It shows which portfolio company the vendor is pinned to and gives you the two ways to correct it.
<Frame>
<img alt="Vendor Black Kite card showing the matched company, its ransomware index and technical grade" />
</Frame>
**Check Black Kite now** searches your portfolio for this one vendor, by its recorded domains first and then by name. Name search is what makes it useful when the domain never matched. Finding a company **pins it by id**, so every later run matches on that id instead of guessing, and any findings it collects are ingested immediately.
<Frame>
<img alt="Vendor Black Kite card reporting that no portfolio company matched" />
</Frame>
**Domain matching** holds the domains Black Kite records for the company, and below them the domains your team has added. A scan never overwrites what you added by hand. Use it when Black Kite monitors a domain you do not have recorded anywhere.
Two states look like a broken integration and are not:
<Frame>
<img alt="Vendor Black Kite card warning the vendor is outside the monitoring scope" />
</Frame>
<Frame>
<img alt="Vendor Black Kite card showing no ransomware index or grade for an unrated company" />
</Frame>
<Note>
The card only appears once Black Kite credentials are saved. Editing domains needs permission to update vendors; the check button needs permission to run integrations.
</Note>
## Seeing what did not match
A nightly run skips the portfolio companies it cannot attribute to any vendor, and the app does not list them. They are usually companies you monitor in Black Kite but have not created as vendors in Coverbase, or vendors whose recorded website never lined up. To check a vendor you expected to see, open it and use **Check Black Kite now** on its Black Kite card.
## Step 4. Create a detector
Saving the settings above starts collection. It does not raise any alerts on its own. A **detector** decides which collected findings are worth someone's attention.
The monitoring section shows a **Detectors** panel with a **Create detector** button. Click it and Coverbase creates a detector wired to your Black Kite source, then opens it for editing.
You can also start from the detector library under **Configuration → Radar → Detectors → Add detector → From detector library**. Search for *Black Kite* and you will find five ready-made policies, each marked with a Black Kite badge. They are already wired to your source, and cannot be added until the source exists.
<Frame>
<img alt="Detector library filtered to the five Black Kite templates, each showing a Black Kite badge" />
</Frame>
| Template | Use it when |
| - | - |
| **Exploited Vulnerabilities** | You want broad coverage. KEV only, with no susceptibility threshold, because an exploited flaw on a supplier's own infrastructure is urgent regardless of their ransomware score. |
| **Critical Exploitable CVEs** | The broad one is too noisy. CVSS 9.0 and above, with at least a 50% predicted chance of exploitation. |
| **Vulnerability Campaign Exposure** | You want early warning. Focus tags only, which usually arrive before a supplier confirms anything. |
| **Ransomware-Susceptible Vendor Exposure** | The usual starting policy. Both signals, limited to vendors scoring above 0.5. |
| **Highest Susceptibility Watch** | You want a short list. Both signals above 0.8. |
<Note>
A detector keeps the name it was created with. If you adopted these templates before the names were shortened, your existing detectors still read "(Black Kite)" at the end. They keep working. Rename them if you prefer.
</Note>
The detector has its own criteria, and every one of them is a requirement rather than a preference. A finding raises an alert only when its signal is switched on **and** it clears every threshold you have enabled:
| Setting | What it does |
| - | - |
| **Alert on known exploited vulnerabilities** | Whether KEV findings can alert at all |
| **Alert on focus tags** | Whether focus tags can alert at all, optionally narrowed to named tags |
| **Require a Ransomware Susceptibility Index above** | Suppresses alerts for vendors at or below the score |
| **Require a CVSS score of at least** | Suppresses lower-severity vulnerabilities |
| **Require an EPSS probability of at least** | Suppresses vulnerabilities unlikely to be exploited |
Each threshold has its own switch. Switching one off means **no constraint on that criterion**, which is different from setting it to zero.
<Warning>
A vendor Black Kite has not scored does **not** clear a susceptibility threshold. "Above 0.5" cannot be satisfied by a blank. If you want unscored vendors to alert, turn that requirement off rather than setting it to 0.
</Warning>
You also choose which vendors the detector applies to and who reviews its alerts, exactly as with any other Radar detector. Set **Enabled** when you are ready, and save.
<Tip>
Start narrow. Turn on KEV only, keep the susceptibility threshold at 0.5, and watch a week of alerts before widening. Adding a signal later is easier than recovering your team's attention after a noisy first week.
</Tip>
## What an alert looks like
A Black Kite detector's findings reach you as signals in **Radar → Signals**, like any other detector's. Open the signal, and the **Detectors** tab names the vendor, the finding, and the criteria it met, so you can see which rule fired rather than guessing.
A known-exploited vulnerability is always **High**, because it is being exploited in the wild and it was found on that vendor's own infrastructure. A focus tag is **High** when the vendor is also ransomware-susceptible, and **Medium** otherwise.
Vulnerability alerts carry the CVE, the CVSS and EPSS scores, the affected asset Black Kite saw it on, and whether the vulnerability is known to be used in ransomware campaigns. Because the CVE is recorded properly, the alert joins up with everything else Coverbase knows about that vulnerability instead of sitting on its own.
## Checking it is working
The monitoring section shows **Last successful run**. If that says *Not yet run* more than a day after you saved, or the date stops advancing:
| What you see | Usually means |
| - | - |
| **Not yet run** after a day | The first scheduled pass has not happened yet, or credentials were saved after the source. Re-run **Test connection**. |
| Runs succeed, no alerts | Collection is on but no detector is enabled, or every finding is being suppressed by a threshold. Check the **Detectors** panel first. |
| Fewer vendors than expected | Vendor websites do not match the domains Black Kite monitors, or your vendor scope is narrower than you intended. |
| Alerts stopped suddenly | Black Kite credentials may have been rotated or revoked. **Test connection** will say so. |
<Frame>
<img alt="Black Kite monitoring panel warning that no detector is watching the source" />
</Frame>
Most shortfalls come back to matching. If Black Kite monitors `acme-corp.com` and your vendor record says `acme.io`, they will not connect. Correct the vendor's website and it will match on the next run, with no need to re-save anything here.
Timing details:
* **The first run does not wait a day.** A newly connected source is due immediately and gets picked up on the next scheduled pass, not 24 hours later.
* **Vendors past the per-run ceiling are deferred, not dropped.** The most ransomware-susceptible are examined first, and the rest are picked up by the following run. A run that looks short is usually this rather than a failure.
* **A vendor Black Kite has not scored will not clear a susceptibility threshold.** That is a suppressed alert, not a missing finding.
* **KEV is also one of Black Kite's focus tags.** When you have exploited vulnerabilities switched on, Coverbase does not also collect the KEV tag as a write-up, so the same exposure is not filed twice in two shapes.
If credentials fail partway through a pass, **Last successful run** does not advance. It reflects the last pass that completed, so a stale date means a run has been failing.
## Turning it off
**Delete Configuration** removes the credentials and stops everything: no further runs, and no further alerts. Existing alerts and their history are kept.
To pause alerting while keeping collection, disable the detector instead. To stop collecting while keeping your settings, archive the Black Kite source under **Configuration → Radar → Sources**.
## Related
<CardGroup>
<Card title="Supplier Radar" icon="satellite-dish" href="/products/supplier-radar">
What Radar does, and how sources and detectors fit together.
</Card>
<Card title="Detector library" icon="list-check" href="/products/detector-library">
The ready-made detector policies, including the Black Kite ones.
</Card>
<Card title="Security intelligence guide" icon="shield-halved" href="/user-guides/security-intelligence">
Coverbase's own outside-in security rating on the same vendor.
</Card>
</CardGroup>
# Breach notification monitoring guide
Source: https://docs.coverbase.com/user-guides/breach-notification-monitoring
How to monitor state attorney general breach registries and SEC cyber incident filings, and turn a filing that names your vendor into an alert.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the breach registries specifically; for reading and triaging the signals they produce, see the [Radar signals guide](/user-guides/radar-signals). For what Radar does generally, see [Supplier Radar](/products/supplier-radar). For every source Coverbase draws on, see the [source library](/products/source-library).
</Info>
When a company suffers a breach affecting residents of a state, the law usually requires it to notify that state's attorney general. Some of those offices publish what they receive. A public company that suffers a material cyber incident files it with the SEC.
These registries are the closest thing to a primary record of a breach. They carry two advantages over news coverage:
* **They land earlier.** A filing is made within days of discovery. Press coverage, if it comes at all, can be weeks later.
* **They have no editorial filter.** A newsroom covers breaches at companies readers have heard of. A registry lists every filing, including the small processor nobody writes about that happens to hold your data.
The trade-off is that a filing is terse. A row typically gives you the organization, the filing date, how many residents were affected, and which categories of data were involved. That is usually enough to know whether you need to act, and rarely enough to know what happened.
## What Coverbase monitors
The **Breach Notification & Disclosure** group in the source library holds seventeen
sources, and between them they cover all fifty states.
### State attorney general registries
| State | What the filing gives you |
| - | - |
| California | Reporting organization, breach dates, and a copy of the notice sent to residents |
| Delaware | Reporting organization, breach dates, residents affected, and the notice |
| Washington | Reporting organization, breach date, Washingtonians affected, and the categories of information compromised |
| Vermont | Reporting organization, its sector, Vermont residents affected, and the categories of data breached |
| Oregon | Reporting organization, plus the breach, discovery, and notification dates |
| Indiana | The year-to-date register, with dates and Indiana residents affected |
| Texas | Entity, information affected, and the number of Texans notified |
| Hawaii | Breached entity, how the breach happened, Hawaii residents impacted, and the notification letter |
| Rhode Island | The notice itself, dated. Any breach touching more than 500 Rhode Islanders must be reported within 45 days |
| Maryland | Reporting business, Marylanders affected, what information was breached, and how |
| Iowa | The business, its industry, the date reported, and the notice sent to Iowans |
| Massachusetts | Reporting organization, residents affected, and whether the data was encrypted |
| New Hampshire | The notice letters themselves |
### Federal sources
| Source | What it covers |
| - | - |
| HHS OCR | **Every HIPAA breach of 500 or more records, in all fifty states.** The row names the covered entity's state, how the breach happened, and how many people it touched. |
| SEC EDGAR, Form 8-K Item 1.05 | The item a public company files to disclose a material cybersecurity incident. |
| SEC EDGAR, 10-K and 10-Q | Annual and quarterly reports discussing a material cybersecurity incident. |
| FTC | Federal enforcement, including Health Breach Notification Rule actions. The FTC publishes enforcement rather than a register. |
### How all fifty states are covered
Thirteen states publish a register of their own, listed above. The rest are
covered by the sources that are national by construction: **HHS OCR** carries
every HIPAA breach of 500 or more records in every state, **SEC EDGAR** carries
every public company's material cyber incident wherever it is based, and the
**FTC** carries federal enforcement.
One further thing closes much of the remaining gap. A breach affecting residents
of several states must be filed in each of them, so a vendor's breach usually
appears in California or Washington even when the state you care about publishes
nothing of its own.
### Three states we cannot reach at all
**Wisconsin** never collects the data: its law requires notice to affected
individuals only, not to any state agency. **Maine** took its database offline
in June 2026. **Montana's** breach page no longer exists. In each case there is
nothing to monitor rather than something we have not built.
## Why there is no all-50-states source
Every state has a breach notification law, so a vendor must notify. Far fewer states **publish** what they receive, and publishing is what makes a registry monitorable.
New York, and most states, take filings through a portal and publish nothing back. There is no page to watch. Connecticut received over 1,830 breach notifications in 2025 and publishes none of them; North Dakota, New Jersey, South Carolina, New Mexico, Missouri, and Alaska are the same. Maine took its public database offline in June 2026 after fake filings were submitted against real companies.
We check each state directly rather than working from a list, which is how Maryland came back: its register had moved, and the address we had been given redirected to the Attorney General's homepage.
If you have been asked to cover all fifty states, the honest answer is that the data does not exist for most of them. The sources above are the ones that publish. Between them they cover a large share of filings, because a breach affecting residents of several states is filed in each of them, so a vendor's breach often shows up in California or Washington even when your own state publishes nothing.
## Step 1. Add the sources
Go to **Configuration → Radar**, open the **Sources** tab, and click **Add source → From Source Library**. Choose the **Breach Notification & Disclosure** segment.
You can add all seventeen at once with **Add all visible**, or start with a few. You can also skip this step: enabling the detector in Step 2 adds every registry you have not added yet. Ways to choose:
* **Add HHS OCR first if you only add one.** It is the single source that spans all fifty states, and healthcare filings are the largest category of breach most portfolios are exposed to.
* **Add California, Vermont, Oregon, and Maryland next.** These are the largest state registers, so they give you the most coverage for the least setup.
* **Add Washington or Hawaii if data types matter to you.** Their filings name the categories of information compromised, or how the breach happened, so the detail is visible on the row itself without opening the notice.
* **Add Rhode Island if recency matters most.** It is the register that runs closest to the present.
<Note>
Adding a source only starts collection. Nothing alerts until a detector reads it, which is Step 2. Adding sources and stopping there is the usual reason nothing appears to happen.
</Note>
## Step 2. Turn on the detector
Open the **Detectors** tab and click **Add detector → From detector library**. Search for **Breach Notification Filings** (it sits in the **Cybersecurity** segment) and click **Configure** to add it and open it for editing, or **Add detector** to add it with its defaults.
Enabling it adds the seventeen breach registries, plus **HIPAA Journal Breach News**, to your sources where you do not have them already, and scopes the detector to them. The library preview lists them under **Sources**.
This detector is written for registry input specifically. It treats the filing itself as evidence rather than waiting for a second source to corroborate it, which matters because a registry row will never have corroboration at the time it appears. It also knows that the same breach filed in five states is one incident, so a vendor appearing across several registries in the same week does not escalate as if it were five separate events.
In the editor, check two settings:
* **Sources.** The detector arrives scoped to the registries it deployed with. Remove any you do not want. A source you add later is not read by this detector until you add it here.
* **Severity threshold.** The default is Medium. High-only cuts volume to filings involving sensitive or regulated data, such as Social Security numbers, financial account data, or health records.
## Step 3. Check what arrives
Give it a pull cycle. Registries are checked every six hours, and the first pull of a large register such as Oregon brings in its full history, so expect a burst on day one and a much smaller trickle after that.
Go to **Radar → Signals**. A signal from a registry looks different from a news signal: the summary is the filing's own fields rather than prose. That is expected. Triaging what arrives works the same way as any other signal, which the [Radar signals guide](/user-guides/radar-signals) covers.
## What to know when reading these signals
**One breach, many filings.** A company that breached data belonging to residents of several states files in each of them. You may see the same vendor five times in a week. That is the registries working as intended, not a vendor with five problems.
**The filer may not be your vendor.** Registries list the entity that filed. That is often a service provider acting for the company you contract with, or a parent, or a subsidiary. The detector calls this out when it can, but it is worth checking before you open a finding against the wrong party.
**Some filings link to a PDF and some link to nothing.** Coverbase reads a PDF notice where the document has a text layer. Where it does not, or where the state publishes no per-filing link at all, the signal still carries the row's own details: the organization, the date, the count, and the data categories.
**Some states publish in batches, months behind.** Maryland is the clearest case: it loads a year at a time rather than posting each filing, so its rows are useful as vendor history and backfill rather than as early warning. California, Washington, and Rhode Island are the ones to watch for something that happened this week.
**Registries publish what filers assert.** These offices do limited validation. Maine took its portal offline after someone submitted fake filings against real companies. Treat a filing as a strong lead, not a proven fact, and confirm with the vendor before acting on it externally.
## Troubleshooting
| What you see | What is happening |
| - | - |
| Sources are added but nothing alerts. | No detector reads them. Enable **Breach Notification Filings** (Step 2), or add the sources to an existing detector's **Sources**. |
| A burst of old filings on the first day. | The first pull of a large register such as Oregon brings in its history. Later pulls only add new rows. |
| A registry shows **Unavailable** in the source library, or **Paused** in your sources. | Coverbase withdrew it because the page no longer exists, refuses automated requests, or could not be read. It stays listed with the reason. |
| The same vendor appears several times in a week. | One breach filed in several states. Triage it once. |
| Massachusetts or New Hampshire results look like an error page. | Both block automated requests. Tell Coverbase support and rely on the other registries meanwhile. |
## Related
<CardGroup>
<Card title="Working Radar signals" icon="satellite-dish" href="/user-guides/radar-signals">
Reading the signal queue and turning a signal into work.
</Card>
<Card title="Source library" icon="rss" href="/products/source-library">
Every source Coverbase draws on, across all tiers.
</Card>
<Card title="Detector library" icon="filter" href="/products/detector-library">
The full catalog of detectors and what each one looks for.
</Card>
<Card title="Findings Manager" icon="clipboard-list" href="/products/findings-manager">
What to do once you have confirmed a vendor is affected.
</Card>
</CardGroup>
# Building a workflow
Source: https://docs.coverbase.com/user-guides/building-a-workflow
How to build an automation from scratch in Coverbase: pick a trigger, narrow it with conditions, configure the action it takes, test it, switch it on, and then read the runs and the work queue items it produces.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Workflows** area: the list, the editor, the runs page, and the work queue items an automation raises. For the ready-made automations you can apply instead of building one, see [Workflow templates](/user-guides/workflow-templates). For the same engine seen from the API, see [Workflow engine](/integrations/workflow-engine) and [Triggering workflows from external systems](/integrations/triggering-workflows).
</Info>
<Note>
Workflows is an optional module. If you do not see **Workflows** in the left navigation, ask your Coverbase representative to turn it on.
</Note>
A workflow is one or more automations drawn on a canvas. Each automation reads as a sentence: **When** something happens, **If** these conditions hold, **Then** do this. The thing that happens is a change to a record in your workspace (a vendor created, a contract's dates edited, a work queue item completed). The thing it does is write another record, send something, or hand a task to a person.
The mistake people make most often is switching a workflow on before it is finished. A workflow you create by hand starts **Enabled**, so the first automation you save is live as soon as you save it. Turn the switch off while you build, test against one record, then turn it back on.
## The workflows list
Open **Workflows** in the left navigation. Each workflow is a card with a status badge, an **Enabled** switch, a preview of its shape, its name and description, and an **Edit** button. The badge reads **Enabled**, **Disabled** or **Archived**. Search matches names and descriptions. Two buttons sit above the cards: **Browse templates** opens the library, and **New workflow** creates an empty one.
<Frame>
<img alt="The Coverbase workflows list searched for 'vendor', showing workflow cards with status badges, enabled switches and previews" />
</Frame>
Two tabs run across the top of the page: **Workflows** and **Workflow Runs**. The second one is where you read what your automations did.
## Creating a workflow from scratch
<Steps>
<Step title="Create it">
Click **New workflow**. Coverbase creates a workflow called "New workflow" and opens the editor. The right pane shows the workflow's settings: click the name to rename it, and click **Add description** to say what it is for.
</Step>
<Step title="Switch it off while you build">
Turn the **Enabled** switch in the right pane off. A hand-built workflow arrives enabled, and an enabled automation fires on the next matching event.
</Step>
<Step title="Choose how it starts">
Under **Trigger**, pick **Event-driven** (the default: "Runs when a domain event happens, like a vendor being created or an assessment changing status") or **Direct** ("Someone runs this workflow from the UI or API"). Most workflows are event-driven. Choose **Direct** only when a person or an external system will start it on purpose.
</Step>
<Step title="Add the first automation">
Click **Add automation** at the top right of the canvas, or the button in the empty state. The right pane switches to the automation form.
</Step>
</Steps>
<Tip>
If a template already does most of what you want, apply it and edit the copy instead. Applying a template lands you in the same editor, with the steps drawn and the workflow switched off. See [Workflow templates](/user-guides/workflow-templates).
</Tip>
## The editor
The editor has two panes. The canvas on the left draws each automation as a node. The inspector on the right shows the workflow's settings, or the automation you are editing.
<Frame>
<img alt="The Coverbase workflow editor with five automation nodes in two connected groups on the canvas and the workflow settings in the inspector pane on the right" />
</Frame>
### Nodes
A node shows the automation's name, the action it takes, and a count of its conditions. An automation with no parent is an entrypoint and gets a heavier outline. A node spawned from the canvas and not yet saved carries a **Draft** badge. Click a node to open it in the inspector. Drag it to move it; **Clean Up Layout** in the top left toolbar rearranges every node automatically, next to the zoom and **Fit view** controls.
### Edges and how they are labeled
An arrow from one automation to another means the second one listens for an event the first one causes. The label on the arrow is the child's own trigger (for example **Assessment Created** on the arrow into a step that reacts to the assessment a parent step created). Clicking an arrow opens the child's trigger field. Hover an arrow and click the **×** to remove the connection; the dialog explains that the child still exists but will no longer fire from the parent's events.
To add a child, hover a node and click the **+** to its right, or drag from the **+** onto an empty spot to place the child there, or drag it onto another node to connect the two. A child does not have to follow the parent immediately; it fires when its trigger event happens, whoever caused it.
<Note>
An automation whose trigger no upstream automation can cause shows a badge reading **Trigger can't be resolved from upstream**. The link is drawn, but nothing on the canvas will ever fire it. Change the trigger, or connect it to an automation whose action produces that event.
</Note>
### Color and delete
Open an automation and click the actions menu next to its name. **Color** paints a strip on the node so a branch stands out; **Delete** removes the automation. The root of a direct workflow cannot be deleted.
## Building an automation
The automation form has three sections. Name the automation at the top; the name is what you will read on the canvas and on the runs page.
<Frame>
<img alt="The Coverbase automation inspector showing the When, If and Then sections and the work queue item fields" />
</Frame>
### When: the trigger
Click **Select trigger...**. The menu groups events by record (Vendor, Assessment, Contract, Finding, and so on) and each record offers its events. Search across the whole menu with **Search triggers...**.
| Record | Events you can trigger on |
| - | - |
| Vendor | Created, Updated, Deleted |
| Service | Created, Updated, Deleted |
| Engagement | Created, Updated |
| Assessment | Created, Updated, Deleted, Manual Handoff Requested |
| Questionnaire Response | Created, Updated |
| Intake Session | Created, Submitted, Updated, Deleted |
| Org Intake | Disabled, Questionnaire Removed |
| Procurement | Created, Updated, Deleted |
| Review | Created, Updated, Deleted |
| Work Queue Item | Created, Updated, Completed, Deleted |
| Finding | Created, Updated, Deleted |
| Commitment | Created, Updated, Deleted |
| Contract | Created, Updated, Deleted, Expired |
| Dark Web Exposure | Created, Updated, Deleted (see [Dark web monitoring](/user-guides/dark-web-monitoring)) |
| Monitoring Record | Created, Updated, Deleted, Scoping Due |
| Monitoring Record Entry | Created, Updated, Deleted |
| Obligation | Created, Updated, Deleted |
| Sla | Created, Updated, Deleted |
| Risk Register Entry | Created, Updated, Deleted |
| Radar Signal, Radar Case, Radar Detector Result | Created, Updated, Deleted |
| Reassessment | Created, Updated, Deleted |
| Screening Match | Created, Updated, Deleted |
| Vendor Bank Account | Created, Updated, Retired |
| Vendor Contact | Updated |
| Vendor Document | Created, Updated, Deleted |
| Supplier Site | Created, Updated, Deleted |
| Supplier Tax Registration, Supplier Diversity Record | Updated |
| Supplier Update Request | Submitted |
| Supplier Legal Entity Assignment | Assigned, Rejected |
| Workflow Run | Updated, Completed, Failed, Deleted |
| Service Now Record | Created, Updated, Deleted |
| Service Now Sync | Completed |
There is no recurring schedule trigger. To run something at a time rather than on an event, see [Running a workflow yourself](#running-a-workflow-yourself) below.
**Narrowing an Updated trigger.** Every Updated event fires on any edit, including a typo fix. When the trigger is an Updated event, the trigger card gains a second line: **and any of these fields change:** with a field picker underneath. Add the fields that matter (`status`, `assignee_id`, `renewal_date`) and switch **any** to **all** if every listed field must change in the same edit. Leave it empty to fire on every update.
### If: conditions
Conditions are optional. Click the **+** next to **If** to add one. Each condition starts with a target (the record the condition reads) and a variant. When you have more than one, a toggle chooses **Match all** or **Match any**.
| Target | Variants |
| - | - |
| Assessment | Filter, Recommendation, Document collection mode, IRQ threshold |
| Vendor | Filter, Has tags, Tier |
| Contract | Filter, Value |
| Procurement | Filter, Contains reviewer |
| Questionnaire | Filter, Answer |
| Work queue | Items complete |
| Engagement, Evaluated control, Finding, Service, Document, Intake session, Review, Radar signal, Monitoring record | Filter |
| This workflow | Opened by this workflow |
**Filter** is the one you will use most. It opens the same **Add filter** menu as the list pages, so any field you can filter a list by, including custom fields, is a field a workflow can branch on. The field names and operators are documented in the [field reference](/fields/overview).
**Opened by this workflow** makes an automation act only on a review or task that an earlier step of the same workflow created. One opened by hand, or by another workflow, with the same name is ignored. The chained [workflow templates](/user-guides/workflow-templates#how-a-chain-moves) rely on it.
**Items complete** is the gate for human approval: it holds until **all** or **any** work items **related to this automation**, **for this vendor**, or **created during this workflow run** are complete. How to compose that into all-of, any-of and sequential approvals is in [Reviews, approvals and gates](/user-guides/reviews-and-approvals).
Most targets only appear when the trigger can reach their record. A **Filter** target is always offered, but a filter on a record the trigger cannot reach (a contract filter on a **Vendor Created** trigger) is flagged when you save, and the form will not save until you change it.
### Then: the action
Click **Select action...**. Actions are grouped by the record they touch, and the label reads as verb plus record: **Create work queue item**, **Update vendor**, **Send email**.
| Record | Actions |
| - | - |
| Vendor | Create, Update, Update vendor status, Update vendor relationship owners, Derive vendor tier, Enable vendor radar monitoring |
| Service | Update, Update service status |
| Engagement, Contract, Finding, Procurement, Review, Risk, Case, Intake session | Create, Update |
| Assessment | Create, Update, Begin, Complete |
| Documents | Link (attach documents already on the vendor, such as those a questionnaire respondent uploaded, to the triggering assessment or service) |
| Intake | Begin, Finalize |
| Radar signal | Update |
| Work queue item | Create, Update |
| Portal | Create, Send; Send custom portal |
| Email | Send |
| Webhook | Send |
| Workflow | Run |
| Workflow run | Update |
| Jira ticket | Create (only with the Jira integration connected) |
| ServiceNow record | Create, Update, Create one per issue or finding, Send custom request, Upload documents (only with the ServiceNow integration connected; see [ServiceNow workflow actions](/user-guides/servicenow-workflow-actions)) |
Under the action picker, a **Reads:** row lists the records the action needs. A pill marked **Not provided by the selected trigger** means the trigger cannot supply that record, and the form will not save: "This automation reads resources the selected triggers don't provide." Change the trigger or the action.
The configuration below the divider depends on the action. A create or update action shows the record's fields; leave a field empty and the action does not touch it. **Send email** asks for an email template and **To**, **Cc** and **Bcc** addresses. **Send webhook** picks the event type and the target webhooks (see [Webhooks](/integrations/webhooks) and [the Webhooks page](/user-guides/webhooks)). **Run workflow** picks another workflow and either runs it immediately or schedules it for a time, such as seven days after the triggering event.
### Placeholders in action text
Any text field in an action accepts a placeholder that is filled in when the automation runs. Click **Insert variable** next to the field, or type the token by hand.
| Token | Fills in |
| - | - |
| `{{vendor:name}}`, `{{vendor:website}}` | The triggering vendor's name and website |
| `{{vendor:relationship_owners[0].name}}`, `{{vendor:risk_analysts[0].email}}` | The vendor's first relationship owner or risk analyst |
| `{{vendor:contact_personnel[0].email}}` | The vendor's first contact |
| `{{service:name}}` | The triggering service |
| `{{assessment:name}}`, `{{assessment:status}}`, `{{assessment:recommendation}}`, `{{assessment:url}}` | The triggering assessment |
| `{{contract:name}}`, `{{contract:value}}`, `{{contract:renewal_date}}`, `{{contract:url}}` | The triggering contract |
| `{{radar_signal:name}}`, `{{radar_signal:max_severity}}` | The triggering monitoring signal |
| `{{questionnaire:answer:question_perma_id}}` | One answer from the triggering questionnaire response |
The menu only offers variables the trigger provides. Fields that take a person (an assignee, an owner) offer a reference instead of a token: **Vendor relationship owner**, **Vendor risk analyst**, **Assessment assignee**, **Contract owner** and similar, resolved on the record that fired the trigger.
<Warning>
A placeholder with nothing behind it skips the whole action. `{{contract:renewal_date}}` on a contract with no renewal date does not render as blank; the step is recorded as **Skipped** and nothing is written. Put optional values in a field you can leave empty, not in a title.
</Warning>
### Saving
Click **Create** (or **Save**). Fields that fail validation are highlighted. If the save would let automations trigger each other in a circle, a **Possible loop detected** warning lists the steps in the cycle. **Save anyway** if a condition breaks the loop in practice; otherwise change the trigger. Leaving the form with unsaved changes asks you to confirm, and a draft node spawned from the canvas is deleted if you cancel without saving.
## Creating a work queue item
The most common action is **Create work queue item**: a task on a named person's queue, tied to a vendor.
| Field | What it does |
| - | - |
| **Type** | The kind of task, which decides where the item deep-links to (an assessment review, a contract review, an intake request review, and so on). |
| **Title**, **Description** | What the assignee sees in their queue. Both accept placeholders. |
| **Instructions** | Markdown shown when the item is opened. Write the steps to complete the task here. |
| **Assignee** | A person, or a reference such as **Vendor relationship owner**. If this resolves to nobody, the item is not created and the step is **Skipped**. |
| **Vendor** | Leave empty to use the vendor behind the triggering event. If no vendor can be resolved, the step is **Skipped**. |
| **Due date** or **Due in days** | Set one, not both. **Due in days** counts from when the automation runs. |
Creating the item sends the assignee a **Work queue item assigned** email, which is on by default and can be turned off per person under [email notifications](/user-guides/email-notifications). Resolving the item raises a **Work Queue Item Completed** event, which is how a later automation waits for a human.
## Testing and enabling
<Steps>
<Step title="Keep it narrow">
Add a condition that matches a single record: a vendor tag only one vendor carries, or a name filter. Every automation writes real records against live vendors.
</Step>
<Step title="Switch it on and cause the trigger">
Turn **Enabled** on. Make the change the trigger listens for (edit the test vendor, create the test contract). If enabling reports **Possible loop detected**, read the listed steps before choosing **Enable anyway**.
</Step>
<Step title="Read the run">
Open the workflow's **History** tab. A run appears within a few seconds with one step per automation that fired. Open it to see what each step wrote, or why it skipped.
</Step>
<Step title="Widen it">
Remove the test condition, save, and leave the switch on. Changes save as you make them; there is no version history, so a saved edit applies to the next event.
</Step>
</Steps>
### Running a workflow yourself
A workflow whose **Trigger** is **Direct** has a play button next to the **Editor** and **History** tabs. Switching an existing workflow to **Direct** adds a root automation called **Workflow run** whose trigger reads **Running the workflow**; every other automation hangs off it. Its default action is a placeholder you are expected to change.
Click the play button to open **Run workflow**. Fill in the record the run should act on (a vendor, contract, procurement or service) and click **Run workflow**, or **Schedule for later...** and pick a time under **Run at**. Either way you land on the **History** tab. A scheduled run sits in a **Scheduled** section above the runs with **Fires at**, a **Pending** badge and **Triggered by** (**Direct run**, or the workflow whose **Run workflow** action scheduled it). The row's menu offers **Cancel scheduled run**. A schedule whose workflow is disabled or archived by the time it fires is dropped.
External systems start the same run through the API. See [Triggering workflows from external systems](/integrations/triggering-workflows).
## Reading the runs page
**Workflow Runs** (the second tab under Workflows) lists every run in the workspace, grouped by workflow by default. Switch the grouping to **Status** to see everything that failed in one place, or filter by **Status**. Each workflow's own **History** tab shows the same table for that workflow only.
<Frame>
<img alt="The Coverbase Workflow Runs page grouped by status, with In Progress, Completed and Failed groups" />
</Frame>
| Status | What it means |
| - | - |
| **In Progress** | The run has started and no automation has marked it finished. |
| **Completed** | An automation in the run used the **Update workflow run** action to set the status to completed. |
| **Failed** | The loop breaker stopped the run, or an automation set the status to failed. |
| **Canceled** | The run was stopped. |
| **Stalled** | In Progress with no update for fifteen minutes. The badge's tooltip says the run "could be missing an automation to mark the workflow complete". |
<Note>
A run finishes only when you tell it to. A workflow with no **Update workflow run** step stays **In Progress** after its last automation fires and shows as **Stalled** a quarter of an hour later. That is cosmetic for a one-step workflow, but if you want a clean **Completed**, add a final automation whose action is **Update workflow run** with **Status** set to completed.
</Note>
Columns are **Workflow Name**, **Status**, **Started At**, **Completed At**, **Duration** and **# Steps**. Click a row to open the run.
### A single run
The run page shows the run's ID under its title, with **Copy run ID**, then the status card on the left and a read-only copy of the workflow's diagram on the right. The status card is a timeline, newest step first and **Started** at the bottom. Each step names its action and shows its **Input** (the record the trigger supplied) and **Output** (the records it wrote, as links). A step that did not write anything carries a badge:
| Badge | What happened |
| - | - |
| **Skipped** | The action ran but had nothing to do: a placeholder or assignee resolved to nothing, no vendor could be found, no active webhook was subscribed, or the update contained no changes. The message under the badge says which. |
| **Failed** | The action errored. The message is the error. A failed step does not by itself change the run's status. |
An automation whose conditions did not match writes no step at all.
<Frame>
<img alt="A Coverbase workflow run page showing the run ID, a Failed status card with its step timeline, and the read-only diagram" />
</Frame>
**Loops.** If automations keep triggering each other, Coverbase stops the run and marks it **Failed**. The run page opens with an **Automation loop detected** callout that lists the chain (each automation linked to the editor, with "ran 3 times" where it repeated) and marks the step where it stopped with **Loop stopped here**. The breaker trips when a chain of automations is sixteen deep, when the same automation fires three times in one chain, or when the same record is changed twice by the same automation. Fix the trigger or add a condition, then cause the trigger again.
There is no retry button on a run. To run the automation again, cause its trigger again: edit the record, or press the play button on a direct workflow.
## Working the work queue
A work queue item lands in two places. The assignee sees it in the **Work queue** button in the top bar, which shows a count and lists **My Work Queue**. Selecting an item opens a panel with the title, description, instructions and a **Mark as resolved** button, with **Back** and **Next** to move through the queue, and **Go to item** when you are on another page. Resolving it stamps the time and the person, and fires the **Work Queue Item Completed** event that a waiting automation listens for.
Administrators also get **See All**, which opens the **Work Queue Items** page for the whole workspace. Its **Items** tab is a table with a **Filter** menu, search, and four views: **All**, **Open**, **Waiting on vendor** and **Resolved**. **Waiting on vendor** holds pending items whose assessment has a follow-up round out with the vendor; they return to **Open** when the vendor answers. On **Open** and **Waiting on vendor**, **Resolve all** resolves every item in the view, with an undo. The **Activity** tab is the change log across every item.
<Frame>
<img alt="The Coverbase Work Queue Items page with one row expanded to show its instructions and the conditions that raised it" />
</Frame>
| Column | What it shows |
| - | - |
| **Vendor** | The vendor the item is tied to. |
| **Title**, **Description** | What the automation wrote, with placeholders filled in. |
| **Status** | **Pending**, **Resolved** or **Canceled**. |
| **Assignee** | The person whose queue it sits on. |
| **Due Date** | The due date the automation set, as a badge. |
| **Completed At**, **Created** | When it was closed and when it was raised. |
Click a row to expand it. The panel shows the **Instructions** and, for an item a workflow raised, "Work queue item created as a result of the following conditions being met" with the conditions listed. The row's menu offers **Mark as resolved**, **Reopen** (on a resolved item), **Mark as canceled** and **Archive**. Cancel an item that is no longer needed rather than resolving it, so nobody is credited with work they did not do; a canceled item cannot be reopened.
Reassignment and routing to a group instead of a person are covered in [Assignment, delegation and out of office](/user-guides/assignment-and-delegation).
## Who can do what
| Action | Who |
| - | - |
| See the workflows list, the editor and the runs pages | Anyone with read access to workflows |
| Create a workflow, apply a template, edit automations, switch **Enabled** on or off | A role with the workflow create and update permissions |
| Delete (archive) a workflow | A role with the workflow archive permission |
| Resolve or reopen a work queue item | Its assignee, or an administrator |
| Cancel or archive a work queue item, open the **Work Queue Items** page | Administrators |
How roles are assigned is in [Permissions and roles](/user-guides/permissions-and-roles). A template only appears in the library when your role can read the records its trigger uses; the rule is spelled out in [Workflow templates](/user-guides/workflow-templates#which-modules-a-template-needs).
## Troubleshooting
| What you see | What is happening |
| - | - |
| The trigger fired but no run appears | The workflow is **Disabled**, the automation is still a **Draft**, or its conditions did not match. Check the switch on the card, save the automation, and compare its conditions with the record. |
| A step is **Skipped** with "no assignee resolved" | The assignee reference (for example **Vendor relationship owner**) points at a field that is empty on this vendor. Fill in the owner, or assign a named person. |
| A step is **Skipped** with "not vendor-resolvable" | The trigger's record has no vendor behind it (an obligation typed in by hand, an ad hoc screen). The action needs one to file the item against. |
| A step is **Skipped** and mentions a variable | A placeholder in the action's text had no value on this record. Remove it or move it to an optional field. |
| **Not provided by the selected trigger** on an action, and the form will not save | The action reads a record the trigger cannot reach. Change one of them. |
| **Trigger can't be resolved from upstream** on a node | The node is connected to a parent whose action never causes the node's trigger. Reconnect it or change the trigger. |
| **Possible loop detected** when saving or enabling | Two or more automations can trigger each other in a circle. Add a condition that breaks the circle, or confirm if you know a runtime condition already does. |
| A run is **Stalled** | Nothing has updated it for fifteen minutes. If the last automation has already fired, the workflow is missing an **Update workflow run** step; the work it did is not affected. |
| A run is **Failed** with **Automation loop detected** | The loop breaker stopped a chain that kept re-triggering. Follow the links in the callout to the automations involved. |
| An **Updated** trigger fires on every edit | No watched fields are set. Add the fields that matter under "and any of these fields change:". |
| A scheduled run vanished from **Scheduled** without running | The workflow was disabled or archived before the time came, so the schedule was dropped. |
| The templates library hides a shelf you expected | Your workspace lacks the module or your role cannot read its records. See [Workflow templates](/user-guides/workflow-templates#which-modules-a-template-needs). |
## Related
<CardGroup>
<Card title="Workflow templates" icon="wand-magic-sparkles" href="/user-guides/workflow-templates">
The nineteen ready-made automations, and what to change before switching one on.
</Card>
<Card title="Reviews, approvals and gates" icon="gavel" href="/user-guides/reviews-and-approvals">
Using the Items complete condition to build all-of, any-of and sequential approvals.
</Card>
<Card title="Assignment and delegation" icon="user-clock" href="/user-guides/assignment-and-delegation">
Routing work to a group instead of a person, and reassigning what is already queued.
</Card>
<Card title="Field reference" icon="filter" href="/fields/overview">
Every field a Filter condition can read, with its operators.
</Card>
<Card title="ServiceNow workflow actions" icon="server" href="/user-guides/servicenow-workflow-actions">
The ServiceNow steps a workflow can run, and reading what each one sent.
</Card>
</CardGroup>
# Centralized supplier portal
Source: https://docs.coverbase.com/user-guides/centralized-supplier-portal
One page where a supplier signs in and sees every request you have open with them, keeps their own profile up to date, and answers the findings you have raised. How to turn it on and what each setting decides.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For what your suppliers see once they are inside, see [The supplier portal, for suppliers](/user-guides/supplier-portal-for-suppliers).
</Info>
Before this existed, everything you asked a supplier for arrived as its own link in its own email. A supplier with nine open items had nine links in nine threads, no way to see them together, and no way to tell you something had changed unless you happened to ask.
The centralized portal gives each supplier one address. They sign in with their work email, see everything you have open with them, bring their own colleagues in, and keep the details you hold about them current without waiting to be asked.
<Note>
Turning it on changes nothing about links you have already sent. Every `/portal/…` link keeps working exactly as it did.
</Note>
## Turning it on
Go to **Configuration › Portal › Centralized Portal** and switch it on.
The page lists what will change before you flip it, not after. Four things happen:
<Steps>
<Step title="Suppliers get one page">
They sign in and see every request you have open with them, grouped by kind.
</Step>
<Step title="Suppliers bring their own people">
The first person at the supplier to sign in becomes the owner. They can invite colleagues and assign work to them without going through you.
</Step>
<Step title="New invitations lead with the portal">
The button in an invitation or reminder points at the portal. The single-request link stays in the email underneath it, for anyone who would rather not sign in.
</Step>
<Step title="Everything open appears in it">
Including requests you sent before you turned this on. Their own links keep working too.
</Step>
</Steps>
## Naming your portal
**Portal Title**, in the **Branding and Policies** card, is what your suppliers see the portal called, for example "Halstead Third-Party Risk Portal". It heads their home page, names the browser tab, and appears on the sign-in screen, including the one on your own portal domain if you have one. Leave it empty and the portal uses your organization's name. It can be up to 120 characters.
The page saves each change as you make it and says so at the top right. The **Preview** beside the settings draws the portal as a supplier will see it: your logo and accent color, the title, the sections you have on, and the footer.
## Choosing sections
Home, requests, documents, messages and team are always there. Four more are yours to switch on, each with a switch under **Sections**. The settings that belong to a section appear beneath it once it is on.
<CardGroup>
<Card title="Profile" icon="id-card">
What you hold about this supplier: bank accounts, addresses and PO email, tax registrations, diversity records and legal entities. Masked, and read-only until you open something. Its second tab, **Changes**, lists what the supplier has proposed and what you decided; it is on whenever Profile is.
</Card>
<Card title="Obligations and findings" icon="clipboard-check">
The findings and obligations you have raised with them, with their due dates.
</Card>
<Card title="Share documents back to them" icon="folder-open">
Documents you share from the vendor's **Portals** tab, shown on the supplier's **Documents** page alongside the ones they uploaded.
</Card>
<Card title="Submissions" icon="paper-plane">
Requests a supplier may start without being asked. See [Letting suppliers start their own requests](#letting-suppliers-start-their-own-requests).
</Card>
</CardGroup>
Every section is off until you turn it on, including on an organization that has the portal on and never opened this tab.
## What a supplier may change without being asked
With **Profile** on, **Updates Without a Request** decides which parts of their own record a supplier may revise at any time. Nothing is open by default.
| Scope | What it opens |
| - | - |
| **PO Email Address** | Where purchase orders and remittance advice are emailed, on each address they hold with you. |
| **Addresses** | Adding, editing and retiring their own sites. |
| **Bank Accounts** | Adding an account, or replacing one. Waits for your approval while bank review is on. |
| **Tax Registrations** | Registration numbers and exemption declarations. |
| **Diversity Declarations** | Inclusion categories and business size. |
Two scopes cannot be put here at all, and a note under the switches says so:
* **Contact details**
* **Your legal entities**
Those are yours to initiate. If you want either updated, send an update request naming that section, and it opens for that supplier for the life of the request.
<Warning>
The standing scope and an open request's scope add together, they do not narrow each other. A supplier with PO emails standing open, who is then sent a request asking for a new bank account, may do both until that request closes.
</Warning>
### Saying which part needs updating
Update requests are sent through the Coverbase API, with [`POST /v1/vendors/{vendor_id}/update_requests`](/api-reference/supplier-profile#send-an-update-request). The dashboard has no button for them. A request names the sections it covers and can carry a message; with no sections named, it uses **Sections to request by default** from the **Update requests** settings in [Know Your Vendor settings](/user-guides/supplier-information#configuring-it-for-your-organization), and it expires after **Request expires after (days)**.
On the supplier's **Profile**, each section a request names is marked as one you asked about, and they can revise it until the request closes or expires.
## What waits for your approval
A new or changed bank account waits for a person while **Bank changes need a reviewer** is on in [Know Your Vendor settings](/user-guides/supplier-information#configuring-it-for-your-organization), which it is by default. A legal entity assignment waits when **Legal entity assignments need approval** is on there. Everything else a supplier submits from **Profile** (addresses, PO email addresses, tax registrations and diversity declarations) is checked against their country's rules and saved to their record straight away, and the supplier's **Changes** tab tells them so.
You decide bank changes where you already review them: the pending changes on the vendor's **Know-Your-Vendor** tab, or the **Vendor changes** page. Approving writes the change and fires the webhook your finance system listens to. Rejecting lets you give a reason, and the supplier sees it on their **Changes** tab.
## Findings and obligations
With **Obligations and Findings** on, choose what a supplier sees under **Items Suppliers See**:
<CardGroup>
<Card title="Only what you have raised with them" icon="shield-check">
A finding appears once you have created a commitment against it. Recommended: it means nothing reaches a supplier before you decided to ask them about it.
</Card>
<Card title="Every open item on their record" icon="eye">
Every open finding and obligation for that supplier, whether or not you have asked them about it.
</Card>
</CardGroup>
Either way a supplier sees a finding's title, severity, source, status and due date, and what you asked them to do. An obligation shows its type (**Complementary control** or **Shared responsibility**) where a finding shows severity. Analyst notes, severity reasoning and evaluation extracts are never in the list.
## Letting suppliers start their own requests
With **Submissions** on, tick the templates a supplier may start themselves under **Templates They May Start**: a security incident notification, a change-of-control notice, an insurance certificate refresh.
A template appears in that list only after you turn on **Let suppliers start this themselves** in the template editor. Both have to be true, so archiving a template stops offering it without you editing anything here.
What a supplier starts is an ordinary request. It gets a reference number, lands in your queue, carries its own asks, uploads, messages and reminders, and appears wherever your team already watches for work.
## Sending a template on a schedule
In the template editor's **Centralized Portal** block, pick a cadence under **Send On A Schedule**: every month, or every 3, 6, 12 or 24 months. Leave it on **Only when someone sends it** and nothing changes.
Then pick supplier tags under **Send It To**. Only suppliers carrying one of those tags receive the template. With no tags picked nothing goes out: an empty audience means nobody, not everybody.
A daily sweep sends the template to every supplier in that audience with a portal whose last request from it is older than the cadence. Templates on a cadence are listed under **Scheduled Requests** on the Centralized Portal tab. Two things worth knowing:
* A supplier who still has that template open is **skipped, not stacked**. An annual questionnaire nobody answered would otherwise become two open requests, then twelve.
* The clock runs from the send, not from the answer. A supplier who never answers is still asked again on schedule.
## Branding, policies and security
**Branding and Policies** applies to every page a supplier answers a request on, as well as the portal title above:
* **Confidentiality Footer**: text shown at the foot of each answering page. Leave it empty for no footer.
* **Privacy Policy Link** and **Trust Center Link**: shown as links in that footer. Each must be a full link starting with `https://`, and the page says so before saving one that is not.
* Your logo and accent color come from **Organization settings**, not from here.
Under **Security**, **Require a one-time passcode** makes a request link ask for a code emailed to the address it was sent to before anything is shown.
## Where to see whether a supplier has one
Open the vendor and go to its **Portals** tab. The **Centralized Portal** card at the top says whether that supplier has a portal and whether it is **Open** or **Closed**, links straight to it with **Open portal**, and holds three tabs:
* **Open Requests**: everything you have open with them right now.
* **People**: who at the supplier can sign in.
* **Shared Documents**: what you have shared onto their **Documents** page. The tab appears when **Share documents back to them** is on.
Everything you have ever sent them, open or closed, is in **All Requests** under the card. A supplier has no portal until you send them their first request.
<Frame>
<img alt="Centralized Portal card on a vendor's Portals tab, listing four open requests with due date badges and one marked Paused" />
</Frame>
## Pausing, rescheduling or closing one request
**Open Requests** lists each open request with its reference, its kind and when you sent it. Overdue and soonest due come first, and paused requests last. Click a title to open the request. The menu at the end of a row has everything else:
<Frame>
<img alt="Row menu with Change due date, Pause request and Close request" />
</Frame>
| Action | What it does |
| - | - |
| **Change due date** | Moves the due date. Reminders follow the new date. |
| **Pause request** | Puts the request on hold. No reminders go out for it, and the supplier sees it marked **On hold**. They can still open it and answer. |
| **Resume request** | Takes it off hold. The due date moves on by the days it was paused, and you can pick a different date in the same step. |
| **Close request** | The supplier can no longer open or submit it, and its reminders stop. Their portal and their other requests are untouched. You can reopen it from **All Requests**. |
Pausing is for work you still want, but not now, for example while a contract is renegotiated. Close a request you no longer need.
<Frame>
<img alt="Resume this request dialog with a due date moved on by 14 days" />
</Frame>
The supplier sees the hold on their **Requests** page and on the request itself:
<Frame>
<img alt="Supplier's request page with a notice that the customer has put the request on hold" />
</Frame>
## Acting on several requests at once
Tick the box on a row to select that request. Hold Shift and tick another to select every request between the two. Once something is selected, clicking anywhere on a row adds it to the selection or takes it out, instead of opening it. The box above the list selects them all.
A bar then appears at the foot of the page with what applies to your selection: **Pause**, **Resume** and **Close**, each with a count. **Pause** leaves out requests already on hold, and **Resume** counts only the paused ones. Each asks you to confirm first.
<Frame>
<img alt="Open Requests with three of four requests ticked, and a bar offering Pause 3 and Close 3" />
</Frame>
The **All Requests** table under the card selects the same way, and its bar can also reopen closed requests.
## Deciding who can sign in
**People** lists everyone you or the supplier invited, with their role and whether they have signed in yet. Use **Add someone** to invite a person as an **Owner** or a **Contributor**. An owner can invite their own colleagues; a contributor can only answer.
<Frame>
<img alt="People tab listing an invited contributor, two people who signed in, and one person removed" />
</Frame>
Each person's menu has:
* **Make owner** or **Make contributor**.
* **Resend invitation**, for someone who has not signed in yet.
* **Remove access**, which asks you to confirm first.
Someone you remove can no longer sign in to the supplier's portal or open anything in it, and the supplier's own owner cannot add them back. Your team can: open the removed list at the foot of **People** and click **Restore access**.
<Warning>
Removing someone does not recall a link to a single request that was already emailed to them. That link keeps working until you close that request.
</Warning>
## Closing one supplier's portal
To shut a supplier's portal without turning the feature off for everyone, open the menu next to **Open portal** and choose **Close portal**.
<Frame>
<img alt="Close Microsoft's portal dialog with an option to also close its four open requests" />
</Frame>
While it is closed:
* The supplier's people see that it is closed and cannot open anything in it.
* No reminders go out, for the portal or for the requests in it.
* Nothing is deleted.
Tick the box to close each open request too, which also stops their single-request links working. Leave it off and those requests stay open, and each one's own link keeps working, until you close them one by one.
The card then says who closed the portal and when, and **Reopen portal** puts everything back as it was.
<Frame>
<img alt="Centralized Portal card marked Closed with the name of who closed it and a Reopen portal button" />
</Frame>
To close several suppliers' portals at once, go to **Configuration › Portal › All Portals**. Tick the portals under **Supplier portals** (Shift and a row click select the same way as above), then choose **Close** in the bar. The same box offers to close their open requests too.
<Frame>
<img alt="Close this portal dialog with an option to also close its four open requests" />
</Frame>
## Turning it off
The switch is reversible and loses nothing. The customer disappears from each supplier's list, and every `/portal/…` link you have already sent keeps working. Turn it back on and the requests, documents, messages and members are exactly as they were.
A supplier who had access and finds it gone is told what happened rather than being offered a way to ask for access back, because nobody revoked them and their own owner cannot undo this.
## Troubleshooting
| Problem | What to check |
| - | - |
| A supplier says reminders stopped | Look at the vendor's **Portals** tab. A **Paused** badge on the request, or a **Closed** portal, both stop reminders. |
| The due date moved when I resumed a request | Resuming adds the days it was paused. Pick another date in the **Resume request** dialog, or use **Change due date** afterwards. |
| Someone I removed still opened a request | They used a single-request link emailed before you removed them. Close that request. |
| Someone I removed is back on the portal | Only your team can restore a person you removed. Check **People** for who restored them, or remove them again. |
| Closing the portal did not close its requests | That is the default. Close them from each request's menu, or tick the box to close them when you close the portal. |
| There are no boxes to tick on the requests | Your role cannot change portals. Ask an admin for a role that can. |
| There is no Centralized Portal card on the vendor | Either the centralized portal is off for your organization, or you have not sent this supplier a request yet. |
## Related
<CardGroup>
<Card title="The supplier portal, for suppliers" icon="user" href="/user-guides/supplier-portal-for-suppliers">
What your suppliers see once they sign in.
</Card>
<Card title="Supplier information" icon="id-card" href="/user-guides/supplier-information">
The Know Your Vendor settings the portal's Profile section follows.
</Card>
</CardGroup>
# Certificate Vault and prequalification
Source: https://docs.coverbase.com/user-guides/certificate-vault
Read the Certificates page and a vendor's Certificates tab, add or request a certificate, connect ISNetworld, Avetta and EcoVadis, write a prequalification rule set, override a result with a rationale, and connect licensed rating providers to Radar.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Certificates** in the left navigation, a vendor's **Certificates** tab, and the licensed connector panels under **Configuration → External Integrations**. It sits beside [The vendor record](/user-guides/vendor-record) and [Document expiry reminders](/user-guides/document-expiry-reminders). For what the module is, see [Certificate Vault and prequalification](/products/certificate-vault).
</Info>
<Note>
Your Coverbase representative turns on the third-party lifecycle features, including the Certificate Vault, for your organization.
</Note>
The Certificate Vault is one list of every certificate your vendors hold, however it reached Coverbase. Prequalification rule sets read the vault to decide which vendors may be used.
The mistake people make most often is writing a rule that the vault cannot satisfy yet. A rule reads only current certificates, so a vendor whose certificate of insurance has lapsed fails an insurance rule even if the new one is sitting in someone's inbox. Upload or request it, and the result updates.
## Step 1: Read the vault
Open **Certificates** in the left navigation. The top row counts **Certificates** across vendors, those **Expiring in 60 Days**, those **Expired** (and how many are blocking), and the share **From Networks**.
**All Certificates** lists each one with its **Vendor**, **Certificate**, **Source**, **Result**, **Status**, **Expires** and **Verification**. Search by certificate or vendor.
| Source | How it got there |
| - | - |
| **Uploaded · extracted** | Read from a document when it was analyzed: certifications, PCI, SOC 1 and SOC 2 reports, ACORD 25 certificates and insurance policies. |
| **Trust center** | A document collected from the vendor's trust center, such as SafeBase. |
| **Network** | Pulled from ISNetworld, Avetta or EcoVadis. |
| **Added by hand** | Entered with **Add certificate**. |
**Status** is **Valid**, **Expiring** (within 60 days) or **Expired**, worked out when you look. A SOC report counts for a year past the end of its period, and a certificate of insurance only until its first policy lapses.
<Frame>
<img alt="Certificates page with counts for certificates, expiring in 60 days, expired and from networks, the All Certificates table, two prequalification rule sets and the Networks card" />
</Frame>
A vendor's **Certificates** tab shows the same list for that vendor, with its **Prequalification** standing and any **Licensed Ratings**.
<Frame>
<img alt="Certificates tab on the Orbitline Data Services vendor page, showing that no prequalification rule set governs the vendor and two expired certificates, a SOC 2 Type II report and an ISO/IEC 27001:2022 certificate" />
</Frame>
## Step 2: Add or request a certificate
* **Add certificate** records one that no document or network supplies. Choose the **Vendor**, **Type**, **Name**, **Issuer**, **Result or grade** and **Valid To**.
* **Request certificate** asks the vendor to upload it. Choose the **Vendor** and the **Certificate**, add a **Message**, and click **Create request**. Send it to the vendor from the request drawer. The document they return is read into the vault like any other upload. Network grades cannot be requested.
A daily refresh adds certificates from documents that were analyzed before your organization had the Certificate Vault.
### Request renewals in bulk
Filter **All Certificates** (for example, to those expiring within 60 days), select up to 500, and click **Request renewal**. Add an optional **Message** and **Due Date**, both shown to the vendor, and click **Request renewals**. Each vendor gets one supplier portal request covering all of its selected certificates, sent to its contacts.
The requests go out in the background, and the page shows progress, then a summary such as "14 sent, 2 skipped, 0 failed". Each skipped certificate gives its reason. Network grades come from their network, not the vendor, and a vendor with no contact on file cannot be asked. The returned documents fill the vault like any other upload.
## Step 3: Connect networks
Open **Configuration → External Integrations** and find **ISNetworld** and **Avetta** under **Contractor Prequalification**, and **EcoVadis** under sustainability. Each opens a panel:
| Network | Fields | What syncs daily |
| - | - | - |
| [ISNetworld](/integrations/guides/isnetworld) | **Client ID**, **Client Secret**, and **Account ID** (your hiring client ID) | Grades, safety statistics and insurance |
| [Avetta](/integrations/guides/avetta) | **API Token**, **Account ID** (your client ID) | Compliance status, statistics and insurance |
| [EcoVadis](/integrations/guides/ecovadis) | **Username**, **Password** | Scorecards |
Click **Save**, then **Test connection**. The **Networks** card on the Certificates page shows each network's status, certificate count and last sync, with **Sync now**. If a sync fails, the panel and the card show **The last sync failed** with the reason.
## Step 4: Write a prequalification rule set
On the Certificates page, under **Prequalification Rules**, click **Add rule set**.
<Steps>
<Step title="Name it and pick vendors">
Give a **Name**, such as "On-site contractors", and a **Description**. Under **Applies to vendors**, add filters. With no filter, the rule set governs every vendor.
</Step>
<Step title="Add rules">
Every rule must pass for a vendor to qualify. Click **Add rule**, give it a label, and add a condition. Click **Add alternative** for another condition that would also pass it: **Passes when any of these holds**.
</Step>
<Step title="Pick conditions">
Choose a **Condition**:
* **Network grade**: a **Network** and a **Minimum grade**.
* **Network status**: a **Network** and an **Accepted status**.
* **Certificate held**: a **Certificate type**.
* **Insurance coverage**: a **Coverage** type, a **Minimum limit (USD)** and whether **Additional insured** is required.
* **Safety or ESG figure**: a **Figure** (TRIR, EMR, DART rate or ESG score), a **Comparison**, a **Threshold** and optionally a number of **Years**. Every one of the latest years must be reported, or the condition fails.
</Step>
<Step title="Reminders and blocking">
Under **Expiry Reminders**, list the days before a certificate lapses that relationship owners are reminded, comma separated. Turn on **Block new purchase orders until the vendor qualifies or someone overrides** to make the rule set blocking.
</Step>
<Step title="Save">
Click **Save rule set**. Results update shortly. Each rule set shows **Qualified** and **Blocked** counts.
</Step>
</Steps>
## Step 5: Override a result
A vendor's **Prequalification** card shows each rule set as **Qualified**, **Blocked** or **Overridden**. A failing rule set that does not block reads as **Advisory**.
To let a blocked vendor proceed, click **Override with rationale**, write the **Rationale**, and click **Override**. The override lapses as soon as the result changes: a vendor that later qualifies no longer needs it, and one that fails a different rule needs a fresh decision. **Clear override** removes it. **Re-evaluate** runs the rule sets again now.
The same card appears on the Front Door review of an intake request. Issuing a purchase order in Coverbase for a blocked vendor is refused, and workflows can branch on a vendor's prequalification standing.
## Step 6: Connect licensed ratings
Under **Configuration → External Integrations**, the **Bitsight**, **SecurityScorecard**, **RapidRatings** and **Moody's** panels each take credentials. Saving them the first time adds a Radar source for the provider and a rating drop detector on it. Each pull matches the provider's portfolio to your vendors, records the rating, and raises a Radar signal only when a stored rating moved. The first pull is a baseline. A rating the provider reports as zero is recorded as zero. On the detector, **Rating fell by at least**, **New rating below** and **Grade worsened** are requirements in the provider's own units. A rating change alerts only when it clears every requirement that is switched on, and at least one must be on. **Rating fell by at least** and **New rating below** take zero or more. See each provider's guide for the fields and the default drop that alerts.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **Certificates** in the left navigation | The third-party lifecycle features are not on for your organization. | Ask your Coverbase representative. |
| An uploaded SOC 2 is not in the vault | The document has not finished analysis, or was classified as another type. | Wait for analysis, or correct the document type. |
| A certificate disappeared | Its document was reclassified, archived or its analysis cleared, or the network no longer returns it. | Expected. Upload or re-sync to restore it. |
| A vendor fails an insurance rule though it is insured | The certificate is expired, the limit is below the minimum, or **Additional insured** is required but not on the ACORD 25. | Request a current certificate. |
| A TRIR rule fails | One of the latest years is missing. | Ask the network or vendor for the missing year. |
| An override vanished | The result changed. | Expected. Decide again. |
| **The last sync failed** on a network | Wrong credentials, or the network's response did not have the expected shape. | Check credentials with **Test connection**. A shape error stops the pull without archiving certificates. Contact your Coverbase representative. |
| No Radar signals after connecting a rating provider | The first pull is a baseline. | Expected. Signals come from later changes. |
## Related
<CardGroup>
<Card title="Front Door triage" icon="door-open" href="/user-guides/front-door-triage">
Prequalification on the intake review.
</Card>
<Card title="Working Radar signals" icon="satellite-dish" href="/user-guides/radar-signals">
Where rating changes appear.
</Card>
<Card title="Document expiry reminders" icon="bell" href="/user-guides/document-expiry-reminders">
Reminders for documents outside the vault.
</Card>
<Card title="Building a workflow" icon="diagram-project" href="/user-guides/building-a-workflow">
Branch on prequalification standing.
</Card>
</CardGroup>
# Claim check
Source: https://docs.coverbase.com/user-guides/claim-check
Check a vendor's questionnaire answers against the evidence on file, read each verdict and its cited passages, filter by verdict, raise findings, ask the vendor to clarify, and check answers again.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Claim Check** tab on a questionnaire submission. It sits beside [Due diligence methods and the portal](/user-guides/due-diligence-methods-and-portal) and [The issue acceptance chain](/user-guides/issue-acceptance-chain). For what the feature is, see [Claim check](/products/claim-check).
</Info>
Claim check tests each answer on a submission against the vendor's SOC reports, certifications, trust center documents, outside-in scan, licensed ratings and contract terms, and cites the passages it relied on.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
The mistake people make most often is reading **Not covered** as a failure. It means nothing on file speaks to the answer: request the evidence, rather than raising a finding against the vendor.
## Step 1: Run the check
Open the questionnaire submission and choose the **Claim Check** tab. Click **Check all answers**. The tab shows **Checking N of M answers** while it runs, and verdicts appear as each answer finishes. **Stop** ends the run; answers already checked keep their verdicts.
A submission has one check running at a time. Starting another while one runs shows the running one. Each run checks up to 400 answers.
## Step 2: Read the verdicts
The table lists each **Question**, the vendor's **Answer**, the **Verdict**, its **Confidence**, the **Evidence** cited and any **Finding** raised. The header counts contradicted answers, and you can filter the table by verdict.
<Frame>
<img alt="Claim Check table with filters for All, Contradicted, Needs evidence, Not covered and Supported, and five answers with their verdict, confidence, evidence and finding" />
</Frame>
Open a row to see the passages: each names its source (for example **Independent auditor's report** or **Published on the trust center**), whether it is an **Authoritative source** or the **Vendor's own statement**, whether it **Supports** or **Contradicts** the answer, the page, and the quoted text. **Open** the source to read it in place. The verdict also shows beside each question on the submission itself.
<Frame>
<img alt="Claim vs Evidence panel for a question about encrypted backups, marked Contradicted, citing a SOC 2 Type II report exception on page 47 and a supporting passage on page 29, with confidence 0.93 and a raised finding" />
</Frame>
A verdict marked **Answer changed** was made against earlier wording. Check it again.
## Step 3: Act on what you found
Select answers and choose:
* **Raise findings** (or **Raise finding with this evidence** on one answer). Each finding is narrowed to its question and carries the answer, the verdict and the cited evidence. Answers that already have a finding are skipped.
* **Ask vendor to clarify**. Edit the message (a default asks the vendor to clarify and share evidence) and send it. The vendor gets it on their portal request, attached to each question. The vendor sees which question a message is about only when their own form on that request asks it. A submission that did not come through the portal has no thread to ask on.
* **Check again**, for answers whose evidence or wording changed.
Each action reports what it did and what it skipped.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **Claim Check** tab | The third-party lifecycle features are not turned on for your organization. | Ask your Coverbase representative. |
| **This submission has no written or selected answers to check.** | Every answer is empty. | Nothing to do. |
| Many answers are **Not covered** | Little evidence is on file for the vendor. | Request the SOC report or other documents, then check again. |
| **The last check did not finish** | The run failed. | Run it again. Answers already checked keep their verdicts. |
| **Ask vendor to clarify** is unavailable | The submission was not sent through the portal. | Contact the vendor directly. |
| A verdict seems wrong | The cited passages do not say what the verdict claims, or newer evidence is on file. | Read the cited passages, click **Check again**, and reject the action in the Agent Ledger with a note. |
## Related
<CardGroup>
<Card title="Due diligence methods and the portal" icon="magnifying-glass-chart" href="/user-guides/due-diligence-methods-and-portal">
Raising a finding on a question by hand.
</Card>
<Card title="Agent Ledger" icon="book-bookmark" href="/user-guides/agent-ledger">
Every check, and your decision on it.
</Card>
<Card title="Evidence quality and source credibility" icon="shield-check" href="/user-guides/evidence-quality">
How sources are graded.
</Card>
<Card title="Claim check" icon="scale-unbalanced" href="/products/claim-check">
What the feature does.
</Card>
</CardGroup>
# Clause packs and non-standard contracts
Source: https://docs.coverbase.com/user-guides/clause-pack
Map reference clauses to risk domains, build an engagement's clause pack, mark missing clauses for the redline, follow the obligations that will be monitored after signature, and use the Non-standard Contracts report.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Required by Risk Domain** on a reference clause in **Clause Sets**, the clause pack on an engagement's **Contract** tab, and the **Non-standard Contracts** report. It sits beside [Contract Guardian](/user-guides/contract-guardian) and [Monitoring plans](/user-guides/monitoring-plans). For what the feature is, see [Clause packs and non-standard contracts](/products/clause-pack).
</Info>
The mistake people make most often is building a pack before any clause is mapped to a risk domain. With no mappings, the pack has nothing to require. Map your clauses first.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
## Step 1: Map clauses to risk domains
Open **Configuration → Clause Sets**, open a clause set, and open a reference clause. Under **Required by Risk Domain**, click **Add rule**:
1. Choose the **Risk Domain** and the **Minimum Level** (or **Any level**) at which an engagement requires the clause.
2. Turn on **Also require it when this domain has an open issue** if an open issue should require it too.
3. Under **Monitor After Signing**, choose what to monitor once the contract is signed: an evidence request, a scorecard, or watching for vendor notices through Radar and issues. Describe the **Obligation** (for example "provide an annual SOC 2 Type II report") and pick a **Cadence**. Choose **Nothing to monitor** if the clause carries no ongoing obligation.
4. Click **Save rule**.
A clause can have several rules. Rules follow the clause into its new versions.
<Frame>
<img alt="Required by Risk Domain section with an Information Security rule at High or higher, also when an issue is open, watched through Radar and Issues, and a Privacy rule at any level monitored by an annual evidence request" />
</Frame>
## Step 2: Build an engagement's pack
Open the engagement and choose the **Contract** tab. Under **Clause Pack from the Risk Results**, click **Build clause pack**. The table lists each **Required Clause**, why it is **Required Because**, and whether it is **In the Current Draft**:
| State | Meaning |
| - | - |
| **Present** | The latest clause review found it in the draft, with the contract and page. |
| **Missing** | The review did not find it. |
| **Non-standard** | The draft has it, but departs from your standard wording. A callout routes it to Legal, with **Open clause review**. |
| **Added to redline** | Someone marked it to add to the redline. |
| **Not reviewed** | No linked contract has a complete clause review. |
<Frame>
<img alt="Clause pack table with each required clause, the reason it is required, its state in the current draft, and Add to redline or Remove from redline buttons" />
</Frame>
Click **Add to redline** on a missing clause to mark it, or **Remove from redline** to undo. Click **Rebuild** after the risk results, the open issues or the rules change.
## Step 3: Follow the obligations
**Obligations to Monitor After Signature** lists each obligation, where it **Goes To** (**Monitoring Plan · evidence request**, **Monitoring Plan · scorecard**, or **Radar + Issues**), its **Cadence** and its **Status**: **Starts when the contract is signed**, **Needs the clause in the signed contract**, **Monitored, next due** a date, or **Watched for vendor notices**.
<Frame>
<img alt="Obligations table listing eight obligations such as SOC 2 Type II report and bridge letter, each with a cadence, Monitoring Plan or Radar and Issues destination, and a status of Needs the clause in the signed contract or Starts when the contract is signed" />
</Frame>
When the contract handoff completes, clauses that were present or added to the redline count as signed, and their obligations become activities on the engagement's monitoring plan. A clause still missing or non-standard at signature is not monitored.
## Step 4: Use the Non-standard Contracts report
From **Contracts**, open **Non-standard Contracts**, or click **See all non-standard contracts** on a pack. The report lists every clause whose latest review found it non-standard, with the **Contract**, **Vendor**, **Clause**, **Severity**, **Status** (**Non-conforming**, **Missing**, **Needs review**, or **Accepted risk** when you filter for it), the **Risk Domains** it is mapped to, and when it was **Reviewed**. Search, filter by severity, status and risk domain, sort, and **Export CSV**.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| **No clause is mapped to a risk domain yet.** | No rules exist. | Add rules under **Required by Risk Domain** (step 1). |
| Every clause reads **Not reviewed** | No linked contract has a complete clause review. | Link the contract and run a clause review. |
| A clause you expected is not required | The domain's result is below the rule's minimum level, and it has no open issue. | Check the engagement's Risk Summary, or lower the rule's level. |
| An obligation reads **Needs the clause in the signed contract** | The clause was missing or non-standard when the contract was signed. | Amend the contract, or accept the gap. |
| The report is empty | No reviewed contract has a non-standard clause. | Expected. |
## Related
<CardGroup>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
Clause sets and clause reviews.
</Card>
<Card title="Monitoring plans" icon="calendar-check" href="/user-guides/monitoring-plans">
Where obligations are monitored.
</Card>
<Card title="Offboarding and continuity" icon="right-from-bracket" href="/user-guides/offboarding-and-continuity">
The contract handoff that executes the pack.
</Card>
<Card title="The engagement record" icon="route" href="/user-guides/engagement-record">
The Risk Summary the pack follows.
</Card>
</CardGroup>
# The clause set library
Source: https://docs.coverbase.com/user-guides/clause-set-library
The 12 packaged clause standards Coverbase ships: what each one covers, how many clauses it carries, how to pick the right starting point, and what changes when you copy one.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This page is part of the [User Guides](/user-guides/overview) collection and goes with the [Contract Guardian guide](/user-guides/contract-guardian), which covers clause sets end to end. Read this one when you are choosing which packaged set to start from.
</Info>
The library saves you writing a clause playbook from nothing: 12 standards, 311 reference clauses, each written with the rationale, the AI guidance, and four drafted tiers of language already in place. You copy one, run it against contracts you already know the answers on, and tune from there.
## What ships
Every template has the same structure. What changes between them is the risk they are aimed at.
| Template | Clauses | For | Critical clauses |
| - | - | - | - |
| **Enterprise SaaS Subscription** | 26 | Hosted software billed per seat or per unit | 2 |
| **Professional Services & Consulting** | 24 | Engagement letters, SOWs, change orders | 4 |
| **Data Processing & Privacy** | 31 | Any vendor processing personal data for you | 3 |
| **Financial Services Third-Party Risk** | 33 | Vendors to a regulated financial institution | 8 |
| **Healthcare & HIPAA Business Associate** | 29 | Vendors touching protected health information | 10 |
| **AI & Machine Learning Vendor** | 27 | Products that generate, classify or decide using a model | 5 |
| **Infrastructure & Hosting** | 25 | Cloud, colocation, managed hosting, CDN | 5 |
| **Payments & Card Data** | 28 | Processors, gateways, acquirers, payment facilitators | 10 |
| **Staffing & Contingent Workforce** | 22 | Agencies, MSPs, umbrella companies, contractor platforms | 3 |
| **Hardware & Supply Chain** | 23 | OEMs, distributors, contract manufacturers | 3 |
| **Marketing & Advertising Agency** | 22 | Creative, media, performance marketing, influencer platforms | 5 |
| **Reseller & Channel Partner** | 21 | Buying through a reseller, VAR or marketplace | 5 |
<Note>
The library also lists ten older, smaller sets from before these templates, such as **SaaS Vendor Risk Clause Set** (15 clauses) and **Agreement Metadata Clause Set** (4 clauses). They show the category **generic**, and all but the SaaS set carry a single tier of language. This page covers the 12 templates above.
</Note>
<Note>
Severity drives triage order and grouping. It does not change the verdict. The **Critical clauses** column is a useful proxy for how much of a template would block a signature rather than start a negotiation.
</Note>
## Choosing a starting point
Pick by **what the vendor does to your risk**, not by what industry you are in. A hospital buying a CRM wants the SaaS set, not the HIPAA set, unless that CRM will hold patient data.
<AccordionGroup>
<Accordion title="Enterprise SaaS Subscription (the default)">
The commercial spine of a subscription: term, renewal, price protection, termination. Then the data and security obligations that follow your data into someone else's cloud, and the risk allocation that decides who pays when the service fails.
Its two Critical clauses are **Data return and deletion on exit** and **Limitation of liability cap**. Start here for most software purchases and add a second, stricter set later for vendors touching regulated data.
</Accordion>
<Accordion title="Professional Services & Consulting">
These contracts are drafted by the firm and are reliably one-sided on who owns the deliverable and what the fee cap covers. Targets **Ownership of work product**, **Use of client data to train models**, and **Limitation of liability and its measure**. The last matters because a cap expressed as "fees paid" means something very different on a three-month engagement than on an annual one.
</Accordion>
<Accordion title="Data Processing & Privacy">
Built around what a data protection authority asks after an incident: what the processor was permitted to do, who else touched the data, where it went, how fast you were told, and what came back at the end. Its largest category is **Processing Scope** (8 clauses). Use it for a standalone DPA or for the data protection sections of a master agreement.
</Accordion>
<Accordion title="Financial Services Third-Party Risk">
The widest set at 33 clauses, and the one where absence is the finding. Supervisors expect specific provisions to exist (**Regulator examination and access**, **Resolution, stress and step-in**, **Exit plan and stressed exit**), and their absence counts against the institution regardless of how well the vendor performs. Written against OCC/FRB/FDIC interagency guidance, FFIEC and DORA expectations.
</Accordion>
<Accordion title="Healthcare & HIPAA Business Associate">
HIPAA already requires a BAA, so the question is never whether one exists but whether it says more than the statutory minimum. Ten Critical clauses, the most of any template, covering **Permitted uses and disclosures of PHI**, **Subcontractor business associate agreements**, and **Breach and security incident notification**, including who pays for a notification, which the statute does not settle.
</Accordion>
<Accordion title="AI & Machine Learning Vendor">
Not the clauses a security questionnaire asks about. **Training on customer data**, **Ownership of inputs and outputs**, and **Model change, version pinning and deprecation**. The last matters because a model that silently changes under you is a different product from the one you bought.
</Accordion>
<Accordion title="Infrastructure & Hosting">
The commercial risk here is rarely a breach. It is an outage the service credits do not compensate, an egress bill that makes leaving unaffordable, and a deprecation notice shorter than the migration it forces. Heaviest on **Service Levels** and **Security** (6 clauses each).
</Accordion>
<Accordion title="Payments & Card Data">
Ten Critical clauses out of 28. Two risks sit on top of the usual ones: the card brands can fine you for your processor's compliance failure, and the processor holds your money between authorisation and settlement. Covers **PCI DSS compliance and validation**, **Account data compromise and forensic investigation**, and **Card brand fines, assessments and indemnity**.
</Accordion>
<Accordion title="Staffing & Contingent Workforce">
The risk is not the service. It is that the workers are in your building, on your systems, creating your IP, and close enough to your direction that a tribunal may call them your employees. **Worker classification and co-employment** is the clause that matters most.
</Accordion>
<Accordion title="Hardware & Supply Chain">
Physical goods bring risks software does not: a part can be counterfeit, a component can go end of life mid-program, firmware can be tampered with in transit. **Authenticity and counterfeit avoidance**, **Firmware integrity and secure update**, **Supply continuity and allocation**.
</Accordion>
<Accordion title="Marketing & Advertising Agency">
Your name is on everything the agency publishes, and the agency spends your media budget through intermediaries whose economics you usually cannot see. **Ownership of creative work product**, **Third-party rights clearance**, **Media buying transparency and rebates**.
</Accordion>
<Accordion title="Reseller & Channel Partner">
The recurring problem is privity: your contract is with a party that did not build the product and cannot fix it, while the party that can has no contract with you. **Flow-through of manufacturer terms** and **Allocation of liability between reseller and manufacturer** are the two that decide whether you have a remedy at all.
</Accordion>
</AccordionGroup>
<Tip>
Most teams end up with two or three sets, not one: a default SaaS set, a stricter set for vendors touching regulated data, and one for services. You can run different sets against different contracts, so starting narrow costs you nothing.
</Tip>
## Copy one into your workspace
On **Configuration → Clause Sets**, open the **Add Clause Set** menu and choose **Clause Set Library**. Search or filter by category, pick a template, and choose **Create Clause Set**. The copy takes the template's name and is active straight away.
The copy is yours from then on. Every reference clause is written into your workspace as your own row: identifier, name, category, severity, rationale, guidance, component scoping, and all four language tiers. Edit any of it, retune the severities, archive the clauses you do not care about.
<Note>
Nothing syncs back. Editing your copy cannot affect the library, and a later platform update to a template will not overwrite what you have negotiated. If you want the newer version of a template, copy it again as a second set and compare.
</Note>
## What you get inside each clause
Every clause in every template arrives complete. See [Understand a reference clause](/user-guides/contract-guardian#step-3-understand-a-reference-clause) for what each field does.
| Field | What the library gives you |
| - | - |
| **Identifier** | A stable per-template prefix, like `SAAS-001`. Quote it in tickets and email. |
| **Severity** | Already set. Across the library: 63 Critical, 148 High, 81 Medium, 19 Low. |
| **Rationale** | Written for the reviewer who hits the deviation, explaining why the clause earns its place. |
| **Guidance** | Written for the matcher: the aliases the clause hides under, the signals that identify it, and the deviations commonly seen. |
| **Component scoping** | Already scoped, so a liability clause is looked for in the MSA rather than the order form. Most clauses target the `msa` component; the library also scopes to `dpa`, `sow`, `regulatory_rider`, `security_addendum` and others. |
| **Variants** | Four drafted tiers. Every one of the 311 clauses has all four. |
## The four tiers
Each library clause is drafted four times, labeled **Baseline**, **Standard**, **Elevated** and **Critical**. They ascend in stringency: Baseline is what the template will accept from any vendor, Critical is what it would demand of a vendor holding regulated data or running a process you cannot lose.
Take auto-renewal in the SaaS set:
| Tier | Label | The position |
| - | - | - |
| 1 | Baseline | Auto-renews for up to 12 months; either party can stop it with 30 days' notice |
| 2 | Standard | Same, with tighter constraints on how notice may be given |
| 3 | Elevated | No auto-renewal; the subscription expires unless you elect to renew |
| 4 | Critical | Renewal requires your affirmative written election every time |
## How a tier becomes a verdict
The library's four tiers are four escalating *asks*, so a copied set is scored against the ask you are holding this vendor to, rather than by treating a high tier as a bad outcome. That target is the **Standard** tier by default:
| Vendor's language matches | Verdict | Why |
| - | - | - |
| The target tier or anything above it | **Conforming** | They met the ask, or conceded more than you asked for |
| One tier below the target | **Needs review** | Short of the ask, but close enough to be worth a person's judgment |
| More than one tier below | **Non-conforming** | A real deviation from the standard |
So on a fresh copy of the SaaS set, a vendor offering the Critical liability cap passes, one sitting on Baseline gets a look, and nothing is marked down for being too generous.
<Tip>
Move the target when the vendor's criticality warrants it. A vendor holding regulated data can be held to **Elevated** or **Critical**, which promotes the weaker drafts to Needs review and Non-conforming without your rewriting a word of the clause language.
</Tip>
<Note>
A clause set you wrote yourself, rather than forked from the library, is scored the other way round unless you say otherwise: tiers 1-2 **Conforming**, tier 3 **Needs review**, tier 4 and above **Non-conforming**. That suits a set drafted as a ladder of acceptability, from your preferred language down to language you would not sign. Both readings are per clause set, so the two kinds of set can run side by side in one review.
</Note>
## Where to go next
<CardGroup>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
Clause sets end to end: the reference clause anatomy, writing risk-tier variants, running a review, and triaging what comes back.
</Card>
<Card title="Generate a clause set from your own contract" icon="wand-magic-sparkles" href="/user-guides/baseline-contract-extraction">
Already have a template MSA or DPA? Extract a clause set from it instead of, or alongside, copying a library set.
</Card>
<Card title="Import and export clause sets as spreadsheets" icon="file-import" href="/user-guides/clause-set-spreadsheet-import">
Export a copied library set to a workbook to branch it, or bring standards in from a spreadsheet you already maintain.
</Card>
<Card title="Contract components" icon="puzzle-piece" href="/user-guides/contract-components">
The components clauses are scoped to, and how Coverbase decides which part of a contract a clause belongs in.
</Card>
</CardGroup>
# Import and export clause sets as spreadsheets
Source: https://docs.coverbase.com/user-guides/clause-set-spreadsheet-import
Build a clause set in Excel and upload it, or export one back out: the workbook format, every column explained, what happens on re-upload, and how to read the import result.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This page is part of the [User Guides](/user-guides/overview) collection and goes with the [Contract Guardian guide](/user-guides/contract-guardian), which covers clause sets end to end. Read this one when your standards already live in a spreadsheet.
</Info>
Most legal teams already have their clause playbook written down somewhere: a Word annex, a negotiation matrix, a tab in someone's workbook. Rather than retyping it clause by clause, put it in the Coverbase template and upload it. One file can carry several clause sets, each with its full multi-tier variant language.
<Note>
This is an alternative to the three routes in the main guide: copy the packaged library, [generate from your own paper](/user-guides/baseline-contract-extraction), or build by hand. Use whichever gets your standards in fastest. You can mix them, and edit everything afterwards. If your standard is a contract rather than a spreadsheet, baseline extraction is the faster start.
</Note>
## Get the template
On **Configuration → Clause Sets**, open the **Add Clause Set** menu and choose **Download Import Template**. You get an `.xlsx` workbook with three sheets:
| Sheet | Purpose |
| - | - |
| **Clauses** | The only sheet that gets imported. One row per clause. |
| **Instructions** | A copy of the rules on this page, so the file travels with its own documentation. |
| **Reference Values** | The accepted values for Severity, Risk Tier, and Component Types. |
The template ships with two filled-in example rows. Delete them before you upload, or edit them in place; they exist to show the shape.
One workbook can carry up to **1000 clause rows** and must be **10 MB or smaller**. Over either limit the upload is refused whole rather than partly imported, so you never have to work out which rows made it.
<Warning>
Keep the header row on the **Clauses** sheet intact. Columns are matched by header name, not position, so you can reorder or add columns freely, but a renamed or deleted required header fails the upload.
</Warning>
## Fill it in
Each row is one clause. Rows that share a **Clause Set** value are grouped into a single clause set.
### Required columns
<ParamField type="text">
The name of the clause set this clause belongs to. Repeat the same value on every row in the set. A file with `FN Master Agreement` on thirteen rows and `FN Privacy Commitment` on fifteen produces two clause sets.
</ParamField>
<ParamField type="text">
Your stable reference for the clause, like `MSA-001` or `PC-010`. Must be unique within its clause set. This is what reviewers quote in tickets and email, so pick a scheme you can live with.
</ParamField>
<ParamField type="text">
What reviewers see. Use the heading a lawyer would recognize: "Limitation of liability", not "LoL cap v2".
</ParamField>
<ParamField type="text">
One of **Critical**, **High**, **Medium**, or **Low**. Drives triage order and grouping; it does not change the verdict. Reserve Critical for clauses that would block a signature.
</ParamField>
<ParamField type="text">
Every clause needs at least one variant. See [Variants](#variants) below.
</ParamField>
### Optional columns
<ParamField type="text">
Shown on the clause set. Repeat it on every row in the set. It is applied **only when the import creates the set**. Importing into a clause set that already exists never overwrites its description.
</ParamField>
<ParamField type="text">
Written for the AI. This is what tells the matcher how to find and evaluate the clause, and it is the field that most affects your results. The [Contract Guardian guide](/user-guides/contract-guardian) shows the four-section format that works: aliases, typical contract types, extraction signals, common deviations.
</ParamField>
<ParamField type="text">
Written for humans. Why the clause matters, and the context a reviewer needs when they hit a deviation.
</ParamField>
<ParamField type="text">
Which parts of a contract this clause should be found in, separated by `|`. For example: `Master Service Agreement|Order Form|Statement of Work`. Leave blank to apply everywhere. Use the values from the **Reference Values** sheet.
</ParamField>
<ParamField type="text">
Groups related clauses in the clause set view. Leave it out and Coverbase derives one from the clause name (`Fee increase cap` becomes `fee_increase_cap`), which is exactly what happens when you create a clause in the UI without one. Add the column when you want your own taxonomy: `limitation_of_liability`, `indemnification`, `audit_rights`.
</ParamField>
### Variants
Variants define the tiers of language you are willing to accept, from most protective to minimally acceptable. During review, the vendor's actual language is scored against them.
The template ships with three variant slots. Each is a group of three columns:
| Column | Accepted values |
| - | - |
| `Variant N Risk Tier` | `1 - Preferred`, `2 - Acceptable`, `3 - Fallback` (a bare `1`, `2`, or `3` also works) |
| `Variant N Label` | A short name for the tier, like "3% annual cap" |
| `Variant N Clause Text` | The acceptable clause language for that tier |
Rules:
* **Variant 1 is required.** Variants 2 and 3 are optional; leave all three cells of an unused variant blank.
* **Each variant on a clause needs a distinct risk tier.** Two variants both marked `1 - Preferred` fails that row.
* **You can add more slots.** Add `Variant 4 Risk Tier`, `Variant 4 Label`, and `Variant 4 Clause Text` columns and they will be imported. Tiers run from 1 to 5.
* **Tiers do not have to be contiguous.** A clause with a Tier 1 and a Tier 3 and nothing in between is normal.
<Tip>
A single Tier 1 variant is a floor, not a playbook: it marks anything that is not your exact preferred language as needing review. If your file has one variant per clause, expect a noisy first review. Add the language you would accept in negotiation before you run the set against a live contract.
</Tip>
## Upload it
On **Configuration → Clause Sets**, open the **Add Clause Set** menu, choose **Import from Spreadsheet**, drop the file in, and choose **Preview import**. Files must be `.xlsx` or `.xlsm`.
Coverbase reads the **Clauses** sheet only (or the first visible sheet, if there is no **Clauses** sheet). The Instructions and Reference Values sheets are ignored, so you can annotate them freely.
Nothing is saved at the preview. Coverbase checks every row first and says what would happen, for example "28 rows: 26 to create, 0 to update, 2 won't import". Rows that will not import are listed under **Why N rows won't import** with the row number, the value given, and the problem. **Download workbook with problems marked** gives you the file back annotated. Choose **Import N rows** to import the rest, or drop in a fixed workbook to check again.
### What happens to each row
The preview counts every row in one of three states.
<AccordionGroup>
<Accordion title="To create" icon="check">
The clause will be added, with all of its variants. New clauses land at the end of their clause set, in file order.
</Accordion>
<Accordion title="To update" icon="circle">
A clause with that Identifier is already in the target clause set. Despite the label, the row is skipped and **nothing about the existing clause changes**.
An accidental re-upload of a stale file cannot overwrite language your team negotiated. It also means the spreadsheet is not an editing tool: to change a clause that is already in Coverbase, edit it in the clause detail view, where the change is versioned and the old wording is kept.
</Accordion>
<Accordion title="Won't import" icon="triangle-exclamation">
Something in the row could not be read: an unrecognized severity, a component type that is not in the reference list, a clause with no variants, two variants sharing a tier, or a missing required value.
Rows are independent. One bad row is reported and skipped; every other row still imports. Fix the reported rows and upload the file again. The rows that already imported are counted as "to update" and left alone, so re-uploading the whole corrected file is the normal fix, not a problem.
</Accordion>
</AccordionGroup>
<Note>
If **every** row fails, nothing is saved at all, including any clause set the file would have created. You are not left with an empty set to clean up.
</Note>
### New sets versus existing sets
Coverbase matches the **Clause Set** column against the names of your active clause sets, ignoring case.
* **No match**: the clause set is created, and its description comes from the Clause Set Description column.
* **A match**: the clauses are appended to that existing set, keeping its current name and description. New clauses go after the ones already there.
* **Archived sets are not matched.** To replace a clause set wholesale, archive the old one and import the file: you get a clean new set, and reviews that ran against the old one stay readable.
<Warning>
Because matching is by name, renaming a clause set in Coverbase and then re-uploading the original file creates a **second** set rather than adding to the renamed one. Update the Clause Set column in your file when you rename.
</Warning>
## After the import
Imported clause sets are created **active**, so they are immediately available to run. Before you point one at a live contract:
<Steps>
<Step title="Spot-check the variants">
Open two or three clauses and confirm the tier language came across whole. Long clause text is the most common casualty of copy-paste between documents.
</Step>
<Step title="Fill in the guidance">
Clauses imported without a Guidance value still match, but they match on the name alone. Adding aliases and extraction signals is what turns a decent match rate into a good one.
</Step>
<Step title="Run it against a contract you already know">
Pick an agreement whose answers you can predict, run a review, and compare. Tune the tiers before you roll the set out.
</Step>
</Steps>
## Export a clause set
The same workbook works in both directions. On **Configuration → Clause Sets**, select a set, open the **⋯** menu on the right of its header, and choose **Export to Spreadsheet**. You get an `.xlsx` file named after the set (`fn-master-agreement.xlsx`) with the same three sheets a template download has, and one row per clause.
The exported file is a valid import file, which lets you:
<Steps>
<Step title="Branch a playbook">
Export a set, change the **Clause Set** column to a new name, and import it. You get a second set with the same clauses: a regional variant, a stricter tier for a critical vendor, a draft you can edit without touching the live set.
</Step>
<Step title="Review it away from the app">
Send the workbook to counsel who do not have a Coverbase login. Every tier of language is in the file, in the columns they already know how to read.
</Step>
<Step title="Keep a copy">
A point-in-time snapshot of what your standard said, in a format that does not depend on Coverbase.
</Step>
</Steps>
<Warning>
**Export is not an edit-and-put-back loop.** Re-importing an exported file into the *same* clause set does nothing: every Identifier already exists, so every row is counted as "to update" and left alone. That is the same rule that protects against a stale re-upload. To change a clause that is already in Coverbase, edit it in the clause detail view, where the change is versioned.
</Warning>
Two things about the file's contents:
* **Only current, non-archived clauses are included.** Archived clauses and superseded versions are left out, because importing them back would recreate them as new clauses.
* **Variant columns are sized to the set.** A set whose widest clause has five tiers exports five variant slots; a set where every clause has one tier exports one. Clauses with fewer tiers leave the extra slots blank.
Clause text longer than 32,000 characters is truncated in the export, marked with `... [truncated]`, because Excel refuses to open a file with a larger cell. Nothing in Coverbase is changed, but do not re-import a file that shows that marker without restoring the full text first.
## Troubleshooting
| What you see | What it means |
| - | - |
| "Missing required column(s)" | A required header was renamed or deleted on the Clauses sheet. Compare against a fresh template download. |
| "Invalid file format" | The file is not `.xlsx` or `.xlsm`. Export from Excel or Sheets as `.xlsx`; a `.csv` does not work, because it cannot carry multiple sheets. |
| "The file could not be read. Check that it is a valid .xlsx workbook." | The upload is corrupt or is not a workbook. Re-export it. |
| "The Clauses sheet has N rows, more than the 1000 supported in one import." | One workbook can carry 1000 clause rows. Nothing is imported; split the file and upload the parts. |
| "File exceeds the 10 MB limit." | Files are capped at 10 MB. Usually means embedded images or a stray sheet of pasted data; delete those, or split the file. |
| Every row is counted as "to update" | The clause set name matched a set you had already imported into, and every Identifier is already there. Nothing is changed. Expected on a re-upload; check the set contents before assuming it failed. |
| Two clause sets with almost the same name | Trailing spaces or a rename. Names are matched exactly (ignoring case), so `FN Master Agreement ` and `FN Master Agreement` are different sets. |
| A clause imported but never matches during review | Usually empty Guidance, or Applicable Component Types scoped to a component that is not in the contract. Clear the component types to let it apply everywhere and re-run. |
| An exported file imports as all "to update" | You imported it back into the set it came from. Change the **Clause Set** column to a new name first: export branches a set, it does not edit one. |
| An exported clause ends in `... [truncated]` | The clause text was over Excel's 32,000-character cell limit. The full text is intact in Coverbase; restore it in the file before re-importing. |
## Related
<CardGroup>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
Clause sets end to end: the reference clause anatomy, writing risk-tier variants, and running a review.
</Card>
<Card title="Generate a clause set from your own contract" icon="wand-magic-sparkles" href="/user-guides/baseline-contract-extraction">
The other upload path: extract a clause set from your template MSA or DPA.
</Card>
<Card title="The clause set library" icon="book-open" href="/user-guides/clause-set-library">
The 12 packaged clause standards you can copy and then export to branch.
</Card>
</CardGroup>
# Contract Assembly
Source: https://docs.coverbase.com/user-guides/contract-assembly
Import a folder of contracts you already hold. Coverbase groups the documents that belong together, proposes a vendor and a contract for each group, and creates nothing until you confirm it.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Contracts → Assembly**, the bulk import for agreements you already hold. For the contract record each confirmed group becomes, see the [Contracts workspace guide](/user-guides/contracts-workspace). For how Coverbase reads a contract's documents once it exists, see [Contract components](/user-guides/contract-components). To raise one new contract for approval, see [Contract intake and approval](/user-guides/contract-intake-and-approval). To file agreements as they arrive by email, see [The contracts repository](/user-guides/contracts-repository).
</Info>
<Note>
Assembly is part of a newer contracts experience. If you do not see **Assembly** under **Contracts** in the left navigation, ask your Coverbase account team to turn it on.
</Note>
Assembly turns a pile of existing paperwork into contract records. You drop the folder your contracts already live in, such as an export from the system you used before. Coverbase reads each file, groups the documents that make up one agreement (a master agreement with its order forms, amendments and exhibits), and proposes for each group the vendor it belongs to and the contract it becomes. You review the proposals and confirm them, one at a time or in sets.
It does not write or draft a contract, and it does not use clause sets or templates. To prepare an agreement to send, see [Signature templates](/user-guides/signature-templates). To check a contract's language against your standard, see the [Contract Guardian guide](/user-guides/contract-guardian).
The mistake people make most often is expecting the import to create contracts. It only proposes them: nothing appears on the contracts list, and no vendor is created, until you confirm a proposed contract in the review.
## What Coverbase does with the files
| Stage | What happens | Who does it |
| - | - | - |
| Reading | Each file is read once for the parties, the dates, agreement numbers, references to other agreements, what kind of document it is, and a name for the contract. | AI, one pass per file |
| Grouping | The documents are sorted into proposed contracts. Each document gets a role, such as root agreement, amendment, order form or exhibit, and anything the evidence cannot settle is raised as a question for you. | Fixed rules, not AI |
| Vendor matching | Each proposed contract is matched against your vendor list. A model picks among the closest names, or says none of them fits. | AI, choosing only from your vendors |
| Confirmation | A proposed contract becomes a contract, or its documents join one that already exists. | You |
A proposed contract is marked **Ready** only when its vendor is settled, nothing is left to decide, and confidence is at least 90%. Confidence is only as high as the weakest link in the group. A group can reach 90% only when its main agreement is signed and every link in it rests on at least two independent kinds of evidence, for example what the documents say and how the files were filed. File names alone never get there.
If the vendor-matching model is unavailable, Coverbase ranks your vendors by how closely their names match instead, and more proposed contracts wait for you to choose. Neither way ever creates a vendor on its own.
## Before you start
* **Permissions.** Importing and confirming need permission to create contracts. Changing a batch (re-analyzing it, regrouping documents, answering its questions) needs permission to edit contracts across your organization.
* **File types.** PDF, DOC, DOCX, RTF and ODT, up to 100 MB each.
* **Keep the folder structure.** The folder a file sits in is used as evidence for grouping, so drop the export as it came out of the old system rather than flattening it.
* **Zip archives are fine.** Drop the zip as it is. Your browser opens it, step 2 lists what is inside, and each document is uploaded and read on its own with the folders it sat in. Nested archives, system files such as `__MACOSX`, and anything other than the supported file types are left out and listed. An archive over 8 GB uncompressed, or with more than 5,000 documents, is refused: split it into several imports.
* **Scans are fine too.** A PDF with no text on the page, such as a scan of a printout, is left out of every group until you run OCR on it from the review. See [Files that were not grouped](#files-that-were-not-grouped).
* **Duplicate copies.** A copy with the same name and size as another file is skipped on step 1. A copy saved under another name is recognized when the files are read: the first one uploaded is kept, and the others are listed under **Unmatched** as exact duplicates.
* **Vendors.** Nothing to set up. The import matches the vendors you have and proposes the ones you do not.
* **A manifest, if your old system exports one.** A CSV listing each file with the vendor and the agreement it belongs to can be attached on step 2. See [Attaching a manifest](#attaching-a-manifest).
## Import the files
The import is a four-step wizard. The step list on the right shows where you are, and you can click back to any step you have already reached.
<Frame>
<img alt="Assembly batches page with the empty state reading no import batches yet and an import contracts button" />
</Frame>
Open **Contracts → Assembly** and click **Import contracts**. On the contracts list, **Actions** offers the same **Import contracts**, and **View import batches** to open the list of batches.
<Frame>
<img alt="Contracts list with the actions menu open, showing import contracts and view import batches" />
</Frame>
### Step 1: Upload contract documents
<Frame>
<img alt="Upload contract documents step with a drop zone, choose files and choose folder buttons, and a list of seven staged files" />
</Frame>
Drag a folder, a set of files or a zip onto **Drop contracts here**, or use **Choose files** or **Choose folder**. Nothing is uploaded yet: the files are only staged in your browser. The list is headed with the count and total size, and **From Contract export/** when every file came from one folder. Remove a file with the **×** on its row, or all of them with **Remove all**.
Above 500 files, a warning asks you to check this is the set you meant to drop. It is not a limit.
Click **Review import**.
### Step 2: Review import details
<Frame>
<img alt="Review import details step showing files staged, files skipped, total size, the batch name, a list of skipped files, and the optional Manifest card with an Add manifest button" />
</Frame>
**What will be imported** counts **Files staged**, **Files skipped** and **Total size**. Files are set aside for one of three reasons:
| Reason | What it means |
| - | - |
| **Unsupported format** | Anything other than PDF, DOC, DOCX, RTF, ODT or ZIP. |
| **Empty file** | The file has no content. |
| **Duplicate** | A file with the same name and size as one already staged, even from another folder. |
Skipped files are left behind entirely. If one of them matters, fix it and add it in a later import.
A zip gets a card of its own, **Inside** and the zip's name. It counts the documents that will be imported from it, the entries left out and why, and the uncompressed size, and lists the first documents by the path they have in the archive. A zip that cannot be read, or that is over the limits, says so there; click **Remove archive** to import the rest without it.
#### Attaching a manifest
If the system you are leaving can export a list of its files, attach it with **Add manifest** on the **Manifest** card. It is optional. It must be a CSV with a header row and one row per file:
| Column | Accepted headers | What it does |
| - | - | - |
| File name (required) | `filename`, `file name`, `file`, `document`, `document name`, `name` | Says which file the row is about. A path works too, with or without the folders around it. |
| Vendor | `vendor`, `vendor name`, `counterparty`, `supplier` | Files the file's contract under this vendor instead of the one Coverbase would match. A vendor you do not have yet is proposed for you to approve, like any new vendor. |
| Agreement | `agreement`, `agreement id`, `agreement number`, `contract id`, `contract number`, `family` | Files with the same agreement become one proposed contract, and are never grouped with files under another agreement. |
| Folder | `source path`, `path`, `folder`, `source folder` | Where the file sat, when the file name column holds only the name. |
The manifest is your own statement about your files, so where it names a vendor or an agreement it wins over what Coverbase reads from the documents. Coverbase still reads each document's role and still asks the questions it cannot answer inside a contract. Files the manifest does not mention are grouped from their contents as usual.
The card checks the file straight away and says how many rows it read, how many agreements and vendors they name, which columns it did not use, and which rows it skipped and why, such as a row that names no file. A file it cannot use at all, for example one with no file name column, says why, and **Upload and analyze** waits until you fix it or click **Remove manifest**.
A row that names a file missing from the import, or a name two files share, is not dropped silently: after analysis it is listed in the batch's **Details** as a manifest row that names no file in this import, with its line number.
**Batch Name** starts as the folder the files came from, or "Contract import" and today's date. Rename it to something your team will recognize in the list of batches.
Click **Upload and analyze**. This is the point where files leave your browser.
### Step 3: Upload and analyze documents
The step shows two separate waits.
* **Uploading files** counts the files as they upload, with a mark beside each one. The documents inside a zip are listed and uploaded one by one. A file that fails is marked in red with the reason, and **Retry failed files** sends the failed ones again.
* **Reading documents** starts once every file has uploaded. It counts the documents read, and moves through **Ingesting files**, **Analyzing documents** and **Ready for review**.
A file that fails holds the reading back, so the batch is never proposed over part of what you dropped. Retry it, or take it out: click **Upload contract documents** in the step list, remove the file with the **×** on its row, then click **Review import** and **Upload and analyze** again. The files that did upload are then read.
Stay on the page until every file has uploaded, because the upload runs in your browser. Once reading has started you can leave: analysis runs on the server and keeps going. If no file uploads at all, no batch is created.
Click **Continue** when the upload has finished.
### Step 4: Import summary
The summary names the batch ("Contract export is in"), counts what was uploaded, failed and skipped, and says either how many proposed contracts are waiting for review or that analysis is still running. Click **Review proposed contracts** to open the batch. You can open it later from **Contracts → Assembly** too.
## Reviewing a batch
Open **Contracts → Assembly** and click **Open** beside a batch. Each row shows the batch's state (**Ingesting**, **Analyzing**, **Awaiting confirmation**, **Complete** or **Failed**) and a count of files, families (proposed contracts), confirmed contracts and unmatched files.
The review page has three parts:
* **The header**: the batch name and state, **Owner**, **Re-analyze**, and **Confirm N ready**.
* **The summary strip**: six figures, **Files**, **Proposed**, **Confirmed**, **Ready**, **Need a Decision** and **Unmatched**. **Details** opens how many files were received, parsed and OCRed, why files went unmatched, and any manifest rows that name no file in the import.
* **Two columns**: the proposed contracts on the left, and the one you select on the right.
### The list of proposed contracts
The list is ordered by what needs you: proposed contracts with open questions first, then the least confident. Each row shows the proposed name, a status, and a line with the vendor, the number of documents, the years they span, and a confidence percentage. Turn on **Group by vendor** to see them grouped under the vendor each would be filed under. Files that were not grouped are listed under **Unmatched** at the bottom.
| Status | What it means |
| - | - |
| **Ready** | Confidence of 90% or more and nothing to decide. Included in **Confirm N ready**. |
| **Needs a decision** | A question Coverbase will not answer for you. It must be settled before the contract can be confirmed. With more than one, the badge counts them. |
| **New vendor** | No vendor on file matches, and the documents name one Coverbase can create once you approve it. |
| **No vendor** | No vendor is settled: several fit, or the documents name nobody. You choose. |
| **Review** | The vendor is settled, but confidence is under 90%, or you have edited the group. Check it and confirm it yourself. |
| **Added** | Confirmed: its documents are on a contract now. **Open contract** opens it. |
Use the arrow keys to move through the list.
### What a proposed contract shows
The right column opens with the proposed contract's name, status and facts, with **Reject grouping** and **Confirm contract** beside them. Once it is confirmed, **Open contract** takes their place and the documents can no longer be changed here. Below, in order:
1. **Needs a decision**: the questions to settle, when there are any.
2. **Contract**: what the documents become. See [Choosing what the documents become](#choosing-what-the-documents-become).
3. **Documents**: each document, its role, and its effective date. Click a file name to open it: once its proposed contract is confirmed it opens in the document viewer, and before that the file you uploaded opens in a new tab.
4. **What the documents say**: a preview of the components the contract would carry, worked out from the documents' roles. The full reading happens after you confirm.
5. **Evidence**, closed by default: why these documents were grouped. **Grouping** says it in sentences, such as how many documents name the same counterparty, and the rows below list the **Counterparty**, **Back reference**, **Agreement number**, **Defined terms similarity**, **Effective dates**, **Source folder**, **Filename tokens** and **File metadata** it relied on.
### Choosing what the documents become
The **Contract** card offers up to four endings, in the order this group's evidence points to:
| Choice | What confirming does |
| - | - |
| **New contract under** the matched vendor | Creates a contract under the vendor Coverbase matched, shown with **Matched at N%**. |
| **New contract under another vendor** | Creates a contract under the vendor you pick in **Vendor**. **Vendors the matcher considered** lists the closest names, with what each matched on and a score. **Use** picks one; clicking a name opens that vendor in a new tab. |
| **New contract under a new vendor** | Creates a vendor with the name in **New Vendor Name**, then the contract under it. **Add full details** opens the full new vendor form instead, which checks for an existing vendor first. |
| **Add to an existing contract** | Adds the documents to a contract you pick in **Contract**. No new contract is created. |
**Contract Name**, under the choice, starts as the name read from the main agreement. Edit it before you confirm.
What the card tells you before you choose:
* **Nothing preselected.** When several vendors fit, or the documents name no counterparty, the card says so and waits for you. Check the candidates before you pick one: the names are close, and the wrong pick files the contract under the wrong vendor.
* **Recommended** beside **Add to an existing contract**. A contract with the same vendor already covers the date these documents start, so they are probably its paperwork. The card preselects adding them to that contract and says "This deal is already on file." Confirming a new contract instead would record the same deal twice.
* **"Looks like the next term of"** a contract. An existing contract with the same vendor ends within 200 days of when these documents start. Confirming a new contract under the matched vendor links the two as a renewal, so the new contract's [Spend over time](/user-guides/contract-spend#spend-over-time) includes the old one.
A vendor created here is a record with a name and nothing else: no intake and no assessment. Fill in its details on the [vendor record](/user-guides/vendor-record) afterwards. If a vendor with the same name already exists, ignoring punctuation and legal endings such as Inc. and LLC, the contract goes under that vendor instead of a second one.
### Settling what needs a decision
Each question states what depends on it, and each button under it makes the change its label names. An answer applies to that question only: a proposed contract with three statements of work asks about each pair separately.
| Question | Buttons | What each one does |
| - | - | - |
| **"SOW 04.pdf could be additive or superseding."** | **SOW 04.pdf replaces SOW 03.pdf**, **Both are in force** | The first records that the later document replaces the earlier one, and the earlier one is shown struck through. The second records that both stand. To read them first, click their names under **Documents**. |
| **"Two documents look like the same agreement."** | **Keep the signed one, set the other aside**, **Keep both on the contract** | The first takes the unsigned copy out of the proposed contract and lists it under **Unmatched** as **Set aside**, so it is never added to a contract. The second keeps both, the unsigned copy contributing nothing. |
| **"Two master agreements with different dates and no link between them."** | **Split into separate contracts**, **Keep as one contract** | The first gives every master agreement after the earliest a proposed contract of its own, and moves the amendments and orders that hang off it along with it. |
| **"An amendment with no parent agreement in the system."** | **Upload the parent agreement**, **Add to a contract on file**, **Confirm as standalone** | **Upload the parent agreement** opens the import on this batch. Add the parent's file: once it is read, the batch is analyzed again and the amendment is grouped with it. **Add to a contract on file** switches the **Contract** card to **Add to an existing contract**; picking the contract answers the question. **Confirm as standalone** keeps the amendment as a contract of its own. |
| **"… already incorporates 2 earlier amendment(s)."** | **Mark the earlier amendments as incorporated**, **Keep each amendment as separate terms** | The first keeps the amendments with the contract, struck through and marked **Contributes nothing**, and the conformed copy carries their terms. Choose the second only if the "conformed" copy is really a draft. |
| **"32 documents in one family."** | **Split the family**, **Keep as one contract** | A group of more than 25 documents always needs a person. **Split the family** takes you to **Documents** and asks you to tick what belongs to a separate contract, then **Split N out** moves it. |
| **"No vendor in the system matches …"**, **"More than one vendor could be …"**, **"These documents never name a counterparty."** | **Use** and a vendor, **Create** and a name, **Pick another vendor** | Each one fills in the **Contract** card: **Use** files the contract under that vendor, **Create** proposes a new vendor with that name, and **Pick another vendor** opens the vendor picker. A complete **Contract** card answers the question. |
### Fixing the grouping
Every change is available at any time before you confirm.
* **Change a document's role** with the menu at the end of its row: **Root**, **Amendment**, **Restatement**, **SOW**, **Order form**, **Exhibit**, **Evidence**, **Redline** or **Duplicate**. A **Redline**, **Quote** or **Duplicate** is struck through and marked **Contributes nothing**: it stays with the contract for the record and adds no terms.
* **Split documents out.** Tick them and click **Split N out**. They become a new proposed contract with "(split)" after its name. At least one document has to stay behind.
* **Move one document.** Tick exactly one; the menu in the **Documents** header reads **Move to…**. Pick the proposed contract it belongs to.
* **Merge.** With no document or more than one ticked, the same menu reads **Merge into…** and moves this whole proposed contract into the one you pick, whatever is ticked.
* **Reject grouping** drops the proposed contract from the batch. Its files are not deleted, and **Re-analyze** proposes over them again.
A proposed contract you edit drops below 90% confidence, so it leaves **Confirm N ready**. Confirm it on its own, or tick it and confirm it from the selection bar.
### Re-analyzing a batch
**Re-analyze** regroups only the files nobody has worked on yet. What you have done stays as you left it:
* A proposed contract you confirmed stays confirmed, and its files are never proposed again.
* A proposed contract you split, merged, moved documents in or out of, changed a role in, or answered a question on is kept exactly as it is.
* A file you set aside stays under **Unmatched**.
Rejected groups are proposed again, because rejecting one only drops the grouping. Re-analyzing runs on the server: the button reads **Analyzing**, the page cannot be edited until it finishes, and it fills in on its own when it does. **Run OCR** re-analyzes the same way when it finishes.
### Confirming one proposed contract
Click **Confirm contract**, or **Add to contract** when you chose an existing contract. The button stays unavailable until the **Contract** card is complete and no question is open; hover it for the reason. Confirming creates the contract, or adds the documents, and opens that contract. To carry on with the batch, go back to **Contracts → Assembly** and click **Open**: the proposed contract now reads **Added**.
Confirming is done once. Confirming the same proposed contract again, after a double click or a retry, opens the contract it already created rather than making a second one, and **Confirm N ready** never includes a proposed contract that is already confirmed.
### Confirming many at once
Most of a large import is the same answer given many times, so the page is built for confirming in sets.
* **Confirm N ready** in the header confirms every **Ready** proposed contract under its matched vendor. When some are held back only because their vendor does not exist yet, **Create N new vendors** appears beside it. Tick it to create those vendors and confirm their contracts in the same click.
* **Owner** in the header becomes the relationship owner of every contract confirmed in bulk. Set it first. A contract confirmed on its own gets no owner; add one on its **Team** card.
* **Choose your own set** by ticking proposed contracts. Shift-click ticks a range, the checkbox at the top ticks all of them, and **Select** picks **Ready to confirm**, **Needs a new vendor**, **Needs a decision** or **All**. With **Group by vendor** on, a vendor's checkbox ticks all of that vendor's proposed contracts. A proposed contract that reads **Added** cannot be ticked. A bar appears at the bottom of the page:
* **File all under…** files every ticked contract under one vendor you pick.
* **Create N vendors** approves the new vendors proposed in the selection.
* **Confirm N**, or **Confirm N under** the vendor you picked, confirms them.
* **Drop** rejects the ticked groups.
* Press Escape to clear the selection.
Bulk confirmation never answers a question for you. A proposed contract with an open question is skipped, unless the only question is its vendor and you answered it with **File all under…** or by creating the vendors. The message after confirming says how many still need an answer.
## Files that were not grouped
A file that could not be put in any group is listed under **Unmatched**, with the reason:
| Reason | What it means | What to do |
| - | - | - |
| **No text layer** | A PDF with nothing readable on the page, such as a scan. | Click **Run OCR**. |
| **Parse failed** | The file could not be opened or read at all. OCR cannot help. | Save it again in another supported format and add it in a later import. |
| **Exact duplicate** | The same file as another in the batch, saved under another name. The first one uploaded is kept. | Nothing. The copy it duplicates is in the batch. |
| **Not an agreement** | A tax form such as a W-9, an invoice, an insurance certificate, a certification or a SOC report. | Upload it to the vendor's documents if you want to keep it. |
| **No counterparty found** | The document names no other party, and nothing else in the batch links to it. | If it belongs to a contract, upload it on that contract's **Documents** tab. |
| **Set aside** | You kept the signed copy of a document, and this is the unsigned one. | Nothing. It is kept out of every contract. |
Unmatched files are not kept anywhere else in Coverbase. Only documents in a confirmed group become documents on a vendor and a contract.
When the batch holds scans, the summary strip says how many files need a person and offers **Run OCR**. It OCRs every scan in the batch, reads the text it recovered, and re-analyzes, so a scan that becomes readable joins the group it belongs to. A scan OCR could not read stays under **Unmatched**, and once every scan has been through OCR the button is no longer offered, because a second pass would change nothing.
## What a confirmed contract gets
* It is created under the vendor you chose, with the name in **Contract Name** and an effective date taken from the documents. Its type reads **Unclassified** at first.
* The group's files become the vendor's documents and appear on the contract's **Documents** tab, each with the role it had in the group.
* A renewal the batch proposed is linked, as described under [Choosing what the documents become](#choosing-what-the-documents-become).
* Coverbase then reads the new contract's documents as it does for any contract that gains documents: its [components](/user-guides/contract-components) and the priced lines on its [Spend tab](/user-guides/contract-spend) fill in over the next few minutes.
* It has no owner unless you confirmed it in bulk with **Owner** set.
The batch counts each confirmation. When every proposed contract is confirmed or added, the batch reads **Complete**.
## Troubleshooting
| Symptom | Cause | Fix |
| - | - | - |
| **Assembly** is not under **Contracts**. | It is not turned on for your organization. | Ask your Coverbase account team. |
| A file I dropped is not in the list. | It was set aside as an unsupported format, an empty file, or a duplicate name and size. | Check the skipped list on step 2. Convert or rename the file and import it later. |
| A file keeps failing to upload. | The upload did not reach storage. A file over 100 MB always fails. | Click **Retry failed files**. If it still fails, take it out on step 1 as described in [Step 3](#step-3-upload-and-analyze-documents). |
| **Continue** stays unavailable on step 3. | A file failed, so reading is held back until it is retried or removed. | Retry it, or remove it as above. |
| A zip is refused on step 2. | It could not be read, or it is over 8 GB uncompressed or 5,000 documents. | Click **Remove archive** to import the rest, and split the archive into smaller ones. |
| The review page says it is reading the documents. | Analysis is running on the server. | Wait. The page fills in when it finishes. |
| Every proposed contract is **New vendor** or **No vendor**. | Your organization has few vendors yet, or they are named differently from the documents. | Approve the new vendors with **Create N new vendors**, or file groups under existing vendors with **File all under…**. |
| **Confirm contract** is unavailable. | A question is open, or the **Contract** card is incomplete. | Hover the button, answer the questions, and choose a vendor and a name. |
| **Confirm N ready** confirmed fewer than expected. | The rest have open questions, are under 90%, or were edited. | Work through them one at a time, or tick them and use the selection bar. |
| The same deal is now two contracts. | A group was confirmed as new when the deal was already on file. | Archive the new contract from its **Actions** menu, then add its documents to the existing contract with **Link Existing Contract Documents** on that contract's **Documents** tab. |
| A statement of work that replaces another is counted as well. | The question was answered **Both are in force**, or was never raised. | On the contract, check the document's role on the **Documents** tab and the figures on its [Spend tab](/user-guides/contract-spend). |
## Related
<CardGroup>
<Card title="Contracts workspace" icon="folder-open" href="/user-guides/contracts-workspace">
The contracts list and the contract record each confirmed group becomes.
</Card>
<Card title="Contract components" icon="puzzle-piece" href="/user-guides/contract-components">
What each document role means for the contract's terms and money, and how to correct what a document carries.
</Card>
<Card title="The contract Spend tab" icon="coins" href="/user-guides/contract-spend">
Priced lines, the annual total, and spend across the renewals Assembly links.
</Card>
<Card title="The contracts repository" icon="inbox" href="/user-guides/contracts-repository">
Filing agreements one email at a time, rather than importing a back catalog.
</Card>
</CardGroup>
# Contract components
Source: https://docs.coverbase.com/user-guides/contract-components
What each contract component means, how Coverbase decides a document carries it, which contract fields it is allowed to answer, and what happens when two documents claim the same one.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For the screens these components appear on, see the [Contracts workspace guide](/user-guides/contracts-workspace). For the dates they feed, see [Contract dates and reminders](/user-guides/contract-dates-and-reminders).
</Info>
A contract is rarely one file. A master agreement sets the terms, an order form
prices them, an amendment moves the price, and a certificate of insurance proves
one of the obligations. Coverbase reads that pile as a set of **components**: a
component is one subject the contract has an answer to, wherever that answer
happens to live.
This page is the catalog. For each component it says what Coverbase reads it
as, what it does with it, and which of the contract's own fields it is allowed
to change.
## How a component becomes an answer
Three steps, in order.
<Steps>
<Step title="Detection">
Every document is read for the components it carries. One document usually
carries several: a master agreement typically holds master terms, liability,
confidentiality, governing law and notices at once.
</Step>
<Step title="Resolution">
All the instances of one component across all the documents resolve into a
single **slot**, the contract's answer. How they resolve depends on the
component's rule, below.
</Step>
<Step title="Contribution">
Only then may a component change the contract's own fields, and only the
fields it is allowed to carry.
</Step>
</Steps>
### The three resolution rules
| Rule | What it means | Example |
| - | - | - |
| **Singleton** | One answer in force at a time. The latest effective instance wins and the rest become history. | Liability cap. An amendment that raises it replaces the old one. |
| **Series** | A versioned line. The latest is current, and every prior version stays visible. | Order form. Last year's is superseded but still readable. |
| **Set** | Many instances in force at once. | Subprocessors. Five listed in three documents means five subprocessors. |
<Warning>
**Series is not the same as additive.** A series says which version is
current; it does not add the versions together. Two order forms a year apart
are one subscription re-priced, not two subscriptions. Whether money adds or
replaces is decided by the document's role, not by the component's rule.
</Warning>
### Which fields a component may answer
Scanning a whole contract for "the value" finds the wrong number more often
than the right one. The largest figure in a master services agreement is
routinely a \$10,000,000 insurance limit, and the largest in a terms of service
is usually a liability tier. Neither is spend.
So each component is allowed to answer only the fields it can carry. A
term date comes from term and renewal; an amount comes from pricing, an order
form or a statement of work; a cap in the liability component is never mistaken
for either.
<Note>
This narrowing is **opt-in per document**. Until someone confirms what a
document carries, it may answer any field. A narrower question asked of an
unclassified document would lose data rather than clean it. Confirming a
document's components is what turns the narrowing on for that document.
</Note>
## The catalogue
Columns: **Resolves** is the rule above. **May set** is the contract fields this
component is allowed to change. **Feeds** is what else in Coverbase reads it.
### Governing
| # | Component | What Coverbase reads it as | Resolves | May set |
| - | - | - | - | - |
| 1 | Master terms | The governing body of terms the rest hangs off. Establishes the family. | Singleton | - |
| 2 | Order form | What was bought, for how much, and usually for how long. | Series | value, currency, term start, expiry |
| 3 | Statement of work | A scope of services with its own price and deliverables. | Series | value, currency |
| 4 | Term and renewal | When it starts, when it lapses, and whether it renews itself. | Singleton | term start, expiry, renewal date, auto-renew |
| 5 | Milestones and deliverables | What must be delivered and by when. | Set | - |
| 9 | Termination rights | How either side gets out, and how much notice that takes. | Singleton | termination notice period |
| 22 | Governing law | Which law applies and where disputes are heard. | Singleton | - |
| 23 | Assignment and change of control | Whether the vendor may hand the contract to an acquirer. | Singleton | - |
| 24 | Notices | Where formal notice has to be sent for it to count. | Singleton | - |
<Tip>
Component 4 is the one the [renewal runway](/user-guides/contracts-workspace)
runs on, and component 9 sets the notice deadline drawn beside each expiry.
</Tip>
### Commercial
| # | Component | What Coverbase reads it as | Resolves | May set |
| - | - | - | - | - |
| 6 | Pricing and rate card | The priced lines themselves: the rate card, the schedule. | Series | value, currency |
| 7 | Payment terms | When invoices fall due. | Singleton | payment terms |
| 8 | Invoicing and PO reference | Where invoices go and under which PO. | Set | payment terms |
### Performance
| # | Component | What Coverbase reads it as | Resolves | May set |
| - | - | - | - | - |
| 10 | Service levels and credits | The uptime promise and what a miss is worth. | Singleton | - |
| 11 | Support and maintenance | Response times and what support is included. | Singleton | - |
| 33 | Acceptance and testing | What counts as delivered. | Singleton | - |
### Risk
| # | Component | What Coverbase reads it as | Resolves | May set |
| - | - | - | - | - |
| 12 | Liability caps and carveouts | The ceiling on what the vendor owes, and what escapes it. | Singleton | *never sets value* |
| 13 | Warranties and disclaimers | What the vendor promises the product does. | Singleton | *never sets value* |
| 14 | Indemnification | Who defends whom, and against what. | Singleton | *never sets value* |
| 19 | Insurance requirements | The cover the vendor must carry. | Singleton | *never sets value* |
| 20 | Audit rights | Whether you may audit, how often, on what notice. | Singleton | - |
| 21 | Business continuity | Recovery commitments after an outage. | Singleton | - |
<Warning>
The four marked *never sets value* carry the largest currency figures in a
typical agreement, and none of them is spend. They are listed here, rather than
left out, so the reason is on record.
</Warning>
### Data and IP
| # | Component | What Coverbase reads it as | Resolves | May set |
| - | - | - | - | - |
| 15 | IP ownership and license grant | Who owns what, and what you are licensed to do. | Singleton | - |
| 16 | Confidentiality | The confidentiality obligation and how long it runs. | Singleton | - |
| 17 | Data protection addendum | The DPA. Also updates the vendor's data profile. | Singleton | - |
| 18 | Security requirements | The security exhibit. Maps to assessment questions. | Singleton | - |
| 25 | Subprocessors | The fourth parties the vendor uses. Feeds Radar. | Set | - |
| 26 | Cross-border transfer terms | SCCs and transfer mechanisms. | Singleton | - |
| 27 | AI and model terms | Whether your data trains a model. | Singleton | - |
| 36 | End user license | A software schedule or EULA. Grants rights, prices nothing. | Singleton | *never sets value* |
### Execution and provenance
| # | Component | What Coverbase reads it as | Resolves | May set |
| - | - | - | - | - |
| 28 | Signature and execution | Evidence it was signed. Decides in-force status. | Singleton | - |
| 29 | Amendment instrument | The amendment itself, as a link in the chain. | Series | - |
| 34 | Redline and negotiation history | A marked-up draft. **Never in force.** | Set | *never sets value* |
| 35 | Quote or proposal | An offer that was not ordered. **Never in force.** | Set | *never sets value* |
<Warning>
A quote is not an order. A single quote routinely prices one plan two ways at
once, say $500 a month billed quarterly or $400 billed annually, so reading it
as spend books a figure nobody agreed to, and books it twice. A quote is kept
for the audit trail and contributes nothing until an order form or agreement
adopts it.
</Warning>
### Compliance and other
| # | Component | What Coverbase reads it as | Resolves | May set |
| - | - | - | - | - |
| 30 | Unclassified exhibit | An attachment nobody has classified yet. | Set | - |
| 31 | Regulatory riders | Sector-specific riders. | Set | - |
| 32 | Publicity rights | Whether the vendor may name you as a customer. | Singleton | - |
## How a document's role decides what its money does
The component says *what subject* a document answers. The document's **role**
says *what its numbers do to the contract*.
| Role | What its money does | Typical document |
| - | - | - |
| Root | Replaces. It states the terms. | The master agreement. |
| Restatement | Replaces. It restates the whole thing. | An amended and restated agreement. |
| Order form | Adds. | An order form or sales order. |
| Statement of work | Adds. | A SOW or an engagement letter. |
| Amendment | Adds. | An amendment, addendum, or change order. |
| Exhibit | Fills blanks only. | A schedule, a license, an annex. |
| Evidence | Fills blanks only. | A certificate of insurance. |
| Redline draft | Nothing. | A marked-up draft. |
| Quote | Nothing. | A priced offer nobody accepted. |
| Duplicate | Nothing. | A second copy, or a superseded original. |
<Note>
A currency mismatch stops both halves. If a document states a figure in a
currency the contract does not already use, neither the amount nor the
currency label moves. An unconverted total under the wrong label is worse
than no total at all.
</Note>
The individual charges are listed on the contract's [Spend tab](/user-guides/contract-spend).
## How Coverbase decides which document is which
Most of your documents never say, in so many words, what they belong to. A sales
order states its own number and nothing else; an exhibit carries a date older
than the agreement it is attached to. Coverbase reads the shape of the
instrument rather than waiting to be told:
| What it sees | What it concludes |
| - | - |
| An order form, sales order, SOW or fee schedule beside a master agreement | It is **ordered under** that agreement, and what it prices reaches the contract |
| An exhibit, schedule, annex or license | It **hangs off** the agreement, never the other way round, even when the exhibit is the older document |
| A quote or proposal | It is **kept for the record and priced at nothing**, because nobody accepted it |
| Two amendments to the same agreement | **Both stand.** Neither replaces the other |
| Two identical copies of one document | The earlier is the original, the later is marked a **duplicate** |
<Note>
Two different agreement numbers stop the first rule. `S402411` beside `S40241`
is a second agreement, not a line ordered under the first, so Coverbase
groups them but does not add one to the other.
</Note>
Where the documents do not settle it (two order forms a year apart, neither
saying whether the second replaces the first), Coverbase asks you rather than
guessing, because answering it wrong moves money. The same reading groups a whole
folder into contracts when you import one; see [Contract Assembly](/user-guides/contract-assembly).
## Correcting what a document carries
Detection proposes; you decide. On the **Documents** tab, open a document's
components and tick or untick what it carries.
<Steps>
<Step title="Open the editor">
On the contract's **Documents** tab, find the **What the documents say**
card. Switch it to **By document**, find the document, and choose
**Correct components**. The same button sits beside each source when you
expand a component in the **By component** view.
</Step>
<Step title="Correct the list">
Every component in the catalog is offered, and the ones the AI found are
marked **Found by the AI**. Tick what the document carries, untick what it
does not, and set an effective date where the document states one.
</Step>
<Step title="Save and re-read">
**Save and re-read** re-reads the document. Because the corrected list also
narrows what the extraction may believe, the figures it contributes can
change.
</Step>
</Steps>
<Note>
Your correction outlives re-detection. Coverbase rebuilds what the classifier
found each time it re-reads a document, and steps around anything you ruled on
by hand.
</Note>
## What's next
<CardGroup>
<Card title="Contracts workspace" icon="folder-open" href="/user-guides/contracts-workspace">
The list page, the renewal runway, and the cards on a contract record.
</Card>
<Card title="Contract dates and reminders" icon="calendar-days" href="/user-guides/contract-dates-and-reminders">
Which dates Coverbase calculates, and who gets the reminder emails.
</Card>
</CardGroup>
# Contract dates and reminders
Source: https://docs.coverbase.com/user-guides/contract-dates-and-reminders
How the contract timeline works: which dates Coverbase tracks, which ones it calculates for you, who gets the reminder emails, and how to turn a reminder off for a single contract.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the dates on a contract record and the reminders that fire off them. For pulling those dates out of the paper in the first place, see the [Document Insights guide](/user-guides/document-insights).
</Info>
Every contract record carries a timeline: the dates that matter for renewals, notice, and audits, laid out in order. Reminder emails fire off those dates. This guide explains what each date means, which ones Coverbase calculates, and how to stop a reminder on one contract without touching anything else.
## The timeline at a glance
Open a contract and look at the **Terms** card on the **Overview** tab. A track across the top of the card places the dates in order, and the grid under it lists each value beside the terms that produce it. Six dates can appear:
| Date | What it means |
| - | - |
| **Effective date** | When the agreement takes legal effect. |
| **Term start** | When the current term began. |
| **Term end** | When the current term expires. |
| **Notice due** (**Notice due to vendor** in its editor) | The last day you can give notice to terminate or not renew. |
| **Internal action** | Your team's own deadline to decide, ahead of the notice date. |
| **Audit date** | When you have committed to review or audit the vendor. |
Three of the six (**Notice due**, **Internal action**, and **Audit date**) are optional. They appear when they are relevant, and you can turn them off per contract. Effective date, term start, and term end are always shown.
<Note>
Optional does not mean unimportant. The date makes sense on some contracts and not others, so you decide contract by contract.
</Note>
## Fixed dates versus calculated dates
Most surprises come from this distinction.
<CardGroup>
<Card title="Fixed date" icon="thumbtack">
A date you or the document states outright. It sits there until someone changes it. Renewals do not move it: a date the agreement names is a fact, and Coverbase does not rewrite it.
</Card>
<Card title="Calculated date" icon="arrows-rotate">
A date Coverbase works out from other values. **Notice due to vendor** can be calculated as term end minus your notice period. **Internal action** is calculated as the notice date minus your lead time. Both update automatically when the contract renews.
</Card>
</CardGroup>
To see which one you are on, click the date on the track, or its value in the grid. The notice date's editor opens on **Based on term end** (calculated) or **Fixed date**. The internal action's editor offers **Based on notice due** or **Fixed date**.
<Warning>
**A calculated date cannot be deleted.** If **Notice due to vendor** is set to *Based on term end*, deleting it does nothing. It is re-derived from term end minus the notice period when you save, and it comes back for as long as those two values exist. This is the usual cause of a date that will not go away.
</Warning>
The notice date has a third setting for exactly that situation: **No notice date**. Pick it when the contract has no notice deadline to track, or when the deadline would only ever be derived from a term end you are guessing at. It leaves the date blank, stops its reminders, and keeps your term end and notice period intact.
**Term end** can be worked out too. Its editor offers **From term start**: term start (or the effective date, when no term start is set) plus the initial term. Coverbase saves the result as an ordinary date, and from then on each renewal rolls it forward by the renewal term.
<Tip>
**No notice date** and hiding the milestone answer different questions. Choose **No notice date** when the statement is about the *agreement*: there is no such deadline. Hide the milestone when the statement is about *your attention*: the deadline is real, but you do not want to be reminded on this contract. Either one stops the emails.
</Tip>
## What makes a contract renew
A renewal needs two things on the record, and it is the second one people forget.
<CardGroup>
<Card title="Auto-renews is Automatic" icon="toggle-on">
The setting that says renewal happens without anyone doing anything.
</Card>
<Card title="Renewal term is filled in" icon="calendar-plus">
The length each renewal adds. Without it there is nothing to move the term end to.
</Card>
</CardGroup>
Both are on the **Terms** card: click **Auto-renews** or **Renewal term** to open the **Renewal** editor. A nightly job looks at every contract whose term end has passed, and each one either renews or is marked expired.
<Warning>
**Set to auto-renew with no renewal term, a contract gets marked expired.** Not renewed, and not left alone: the job has no term to roll it into, so it does the only other thing it can. The status flips to expired on the term end the paperwork names, which on a long-running agreement can be a date years in the past.
This is the most common cause of "our contracts show the wrong dates". The contracts really are renewing in the world. Coverbase was never told what they renew into.
</Warning>
Filling in the renewal term fixes it going forward and backward at once. The next nightly run renews the contract, moves the term end, puts back the status it had before it expired, and re-derives the notice and internal action dates that hang off the term end.
<Tip>
To find these across the portfolio in one go, click the **Missing renewal details** card on the contracts list, or filter on **Auto-renews** is **Automatic** and **Renewal Term** is empty.
</Tip>
<Note>
Expiry is an organization setting, on by default. The **Automatic expiration** card on the contract statuses page (**Configuration → Statuses → Contract**, or **Actions → Configure lifecycle** on any contract) lets someone who can edit organization settings turn it off and choose the status an expired contract moves to. Only a contract whose status is in the **Started** group, or that has no status, is expired. A contract whose status is in the **Canceled** group is never renewed or expired.
</Note>
### Where the renewal term comes from
Three paths fill it, so most contracts arrive with it already set:
* **Document extraction.** Coverbase reads the renewal term out of the agreement along with the other dates, with a page citation.
* **Spreadsheet import.** The contract import template has a **Renewal Term** column. Fill it in the same shape as the other term columns, for example `1 year` or `12 months`.
* **By hand.** Click **Renewal term** on the **Terms** card and enter it in the **Renewal** editor.
### Recording what you intend to do
A renewal date tells you when to decide. It does not record what you decided, which is why renewals get re-litigated in the week they are due.
The **Renewal decision** row of the **Terms** card takes that answer. Click **Record decision** (or **Change decision**) and choose **Not decided**, **Renew**, **Terminate**, or **Under review**, with a note for the reasoning. The row then shows who recorded it and when. The decision also shows in the **Renewal decision** column of the contracts list and in the preview panel, and it is filterable across the portfolio.
<Note>
**A renewal clears the decision.** When a contract rolls into a new term, the decision and its note go back to empty on purpose. The old answer was about the term that ended, and the new one deserves its own look.
Nothing is lost: every decision is filed in the contract's activity trail with the note, who recorded it, which term it was about, and that term's end date. The card shows the current term, the trail shows the history.
</Note>
## Who gets reminded, and when
Reminders are email, and they come from two places:
<Steps>
<Step title="Organization-wide rules">
Set once for the whole org from the contracts list, under **Actions → Configure notification**. For example: "email 60, 30, and 7 days before the notice due date." Every contract inherits these unless it has its own rules.
</Step>
<Step title="Contract-specific rules">
Set on one contract with **Configure** on the **Reminders** row of the **Terms** card, or **Actions → Configure reminders** in the contract header. Both are for admins. These replace the org-wide rules for that trigger on that contract, which is useful for a contract that needs six months of warning instead of one.
</Step>
</Steps>
Recipients are the contract's relationship owners and watchers, plus any extra addresses on the rule. The **Reminders** row says how many reminders are scheduled and whether they are inherited from the global settings or set for this contract. Click it to see exactly what is queued and who will receive it.
<Tip>
The org-wide notification settings apply to every contract. Changing them to silence one contract silences it everywhere. Use the per-contract control below instead.
</Tip>
## Turning off a reminder for one contract
There are two ways, and neither touches any other contract. Use **No notice date** (above) when the contract has no notice deadline. Use the steps below (hiding the milestone) when the deadline is real but you do not want to be reminded about it here. Hiding works on all three optional dates, whether they are fixed or calculated.
<Steps>
<Step title="Open the contract and find the timeline">
On the contract's **Overview** tab, find the **Terms** card.
</Step>
<Step title="Click the date you want to silence">
Click **Notice due**, **Internal action**, or **Audit date** on the track. The editor opens.
</Step>
<Step title="Choose Hide and stop reminders">
At the bottom of the editor, select **Hide and stop reminders**. The date leaves the timeline (the notice and internal action marks read **Hidden** instead) and its reminder emails stop for this contract.
</Step>
</Steps>
What that does, precisely:
* **The reminders stop for this contract only.** Your org-wide rules are untouched, and every other contract keeps reminding as before.
* **Nothing is deleted.** The date, the notice period, and the page citation from the source document all survive.
* **It is reversible.** Click the **Hidden** mark, or use the **+** (**Add milestone**) beside the track, to bring the date back with its value and reminders intact.
<Note>
Silencing **Notice due to vendor** also silences both notice reminders (the notice-due one and the older termination-notice one, which name the same date) and the **Internal action** reminder when that date is set to *Based on notice due*, because it is only a lead time on the notice deadline.
An **Internal action** date you have pinned to a *Fixed date* is a commitment of its own and keeps reminding. Hide it separately if you do not want it.
</Note>
The reminder details tell you when this is in effect: open the **Reminders** row, and a line at the bottom names each hidden date, so a rule that looks configured but never fires is explained.
### Hiding for this term only
On a contract that renews automatically and has a renewal term, the editor offers a second choice above **Hide and stop reminders**: **Hide until this contract renews**. The reminders stop for the current term and start again on their own when the contract renews, and the reminder details say so.
Use it when you have decided to let this term roll over and want the countdown back next term, rather than never again. It is offered on a notice date set to *Based on term end*, and on an internal action that follows it. A fixed date and the audit date do not move when the contract renews, so there would be nothing left to remind you about, and the choice is not offered there.
### Which one to reach for
The clearest case is an **estimated term end**. If the term end is your best guess rather than a date the contract states, a notice deadline calculated from it is also a guess, and being reminded to act on a guess is noise. **No notice date** is the right choice here: the derived deadline is not real. Keep the estimated term end for planning; switch the notice date back to *Based on term end* if the term end firms up.
Hiding fits when the deadline is real and you do not want to be reminded of it:
* A contract that auto-renews on terms you are happy with, where you do not intend to give notice. If that is a decision about this term only, use **Hide until this contract renews**.
* An audit date that belongs to a different team's process and should not page yours.
* A contract in the middle of renegotiation, where the current dates are about to be replaced.
## Seeing every contract's dates at once
The dates on one contract drive its reminders. To see them across the portfolio, use the **renewal runway** on the contracts list page.
<Frame>
<img alt="Renewal runway with one lane per contract showing the notice deadline, the required notice span, and the current term end" />
</Frame>
The runway is the second view of the contracts list, behind the toggle on the toolbar. It draws one lane per contract on a year of days from today: a hollow circle on the **notice due to vendor** date, a filled dot on the **term end**, and a line between them for the notice you have to give.
Hover either mark to read its date. A lane with no notice date says so where the circle would be, so a missing deadline is never mistaken for a distant one.
<Tip>
The notice date is the one that binds. A term ending in April may need notice in January, and on the runway that is the hollow circle three months to the left of the dot.
</Tip>
For the toggle and the rest of the list page, see the [Contracts workspace guide](/user-guides/contracts-workspace).
## Troubleshooting
| What you see | What is happening |
| - | - |
| "I only see **Edit**, no on/off switch." | The switch is inside the editor. Click the date, then look at the bottom of the panel for **Hide and stop reminders**. |
| "It won't let me clear the date." | The date is calculated, so deleting it re-derives it on save. Open the notice date and choose **No notice date** instead. |
| "The date came from the uploaded document." | That does not lock it. Hiding the milestone overrides the extracted date, and you do not need to re-upload or edit the document. |
| "I turned it off in the org notification settings and it's still emailing." | Org-wide settings apply to every contract. To silence one contract, hide the date on that contract. |
| "I still want to see the date, but not the emails." | Today, hiding does both. If you need the date visible but silent, tell your Coverbase contact. |
| "A date I hid came back by itself." | It was hidden with **Hide until this contract renews**, and the contract renewed. Hide it again, or choose **Hide and stop reminders** to keep it hidden. |
| "I hid the notice date but I'm still getting internal action reminders." | That action date is pinned to a fixed date, so it stands on its own. Only an action date set to *Based on notice due* follows the notice date. Hide **Internal action** as well. |
## Related
<CardGroup>
<Card title="Document Insights guide" icon="file-magnifying-glass" href="/user-guides/document-insights">
Where the dates come from: define the fields Coverbase extracts from every document, each with a page citation.
</Card>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
The language-level half of contract intelligence: clause sets, risk tiers, and clause reviews.
</Card>
</CardGroup>
# Contract Guardian guide
Source: https://docs.coverbase.com/user-guides/contract-guardian
Set up and run Contract Guardian: build a clause set from the library or your own paper, write risk-tier variants, run clause reviews, decide each flagged clause, and export a redlined Word file for the vendor.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the clause-review half of Contract Guardian. For the field-extraction half (pulling dates, caps, and terms out of every document), see the [Document Insights guide](/user-guides/document-insights).
</Info>
Contract Guardian measures how far a contract is from language your legal and risk teams would accept.
You write down your standard once. Coverbase then reads each contract, finds the vendor's language for each of your standards, decides which tier of acceptability it lands in, and hands your reviewer a short list of deviations with the source text quoted and highlighted. Reviewers triage that list instead of reading agreements end to end.
<Note>
Guardian decides **which clauses deviate and how badly**, then writes the asks up for you. It does not negotiate. You still review the marked-up file and decide what to send.
</Note>
## The two halves of contract intelligence
<CardGroup>
<Card title="Document Insights" icon="file-magnifying-glass" href="/user-guides/document-insights">
Field-level. Pulls values out of every document (effective date, liability cap, notice period, governing law), each with a page citation. Runs automatically on upload.
</Card>
<Card title="Clause Review" icon="scale-balanced">
Language-level. Compares the vendor's actual clause language against the tiers you have defined as acceptable, negotiable, and unacceptable. Runs when you start a review.
</Card>
</CardGroup>
They stack: insights populate the contract record and the AI summary, and clause review scores the paper against your playbook. Set up insights first if you only have time for one; it is faster and applies to every document. Set up clause review when you are ready to standardize legal review.
## Before you start
<Steps>
<Step title="Confirm the modules are on">
You need the **Contracts** module, and **Clause review** on top of it. If your contract records do not show a **Review** tab, clause review is not enabled for your organization yet, so ask your Coverbase contact.
</Step>
<Step title="Confirm your permissions">
Building or changing a clause set needs permission to update every contract in your organization, not only the ones assigned to you. Coverbase refuses a clause set change from anyone without it, including an import. If **Configuration → Clause Sets** is not in your navigation, an admin needs to grant it.
</Step>
<Step title="Have a few real contracts loaded">
You will want two or three executed agreements to test your clause set against, plus, ideally, a copy of your own standard paper (your template MSA or DPA), which Guardian can turn into a clause set for you.
</Step>
</Steps>
***
## Step 1: Get contract documents in
Clause review runs against a **contract record** and the documents linked to it.
1. Upload the agreement from **Actions → Upload Documents** on the contracts list, from the contract's **Documents** tab, or from the vendor's Documents tab.
2. **Confirm the document type.** Types like Master Service Agreement, Order Form, Statement of Work, NDA, DPA, Terms of Service, SLA, Software License Agreement, Contract Amendment, and Contract Addendum are what mark a document as contract paper. Type inference is good but not infallible on unusual formats, and scope decisions downstream key off the type.
3. Link every document that makes up the agreement to the same contract record: the MSA, the order form, the DPA, the security addendum, the amendments. Guardian analyzes the set, not the file.
<Frame>
<img alt="Contract overview with extracted terms and AI summary" />
</Frame>
<Tip>
Amendments and addendums matter here. Guardian detects the logical components inside your linked documents. It will tell an order form apart from the MSA it hangs off, and an AI addendum apart from the DPA, and it scopes each of your clause standards to the components where that clause belongs.
</Tip>
***
## Step 2: Build your clause set
A **clause set** is your playbook: a named collection of reference clauses, each with the language tiers you are willing to accept. You can have several: a standard SaaS set, a stricter set for vendors touching regulated data, a professional-services set.
Go to **Configuration → Clause Sets**. There are three ways to start, and most teams use the first two together.
### Start from the clause set library
<Note>
Coverbase ships 12 packaged clause standards you can copy into your org in one click, pre-written with severities, guidance, and full multi-tier variant language.
</Note>
Open **Add Clause Set** and choose **Clause Set Library**, pick a template, and choose **Create Clause Set**. The copy takes the template's name. Between them the templates carry 311 reference clauses, already scoped to the right contract components and already tiered:
| Template | Clauses | For |
| - | - | - |
| Enterprise SaaS Subscription | 26 | Hosted software billed per seat or per unit |
| Professional Services & Consulting | 24 | Engagement letters, SOWs, change orders |
| Data Processing & Privacy | 31 | Any vendor processing personal data for you |
| Financial Services Third-Party Risk | 33 | Vendors to a regulated financial institution |
| Healthcare & HIPAA Business Associate | 29 | Vendors touching protected health information |
| AI & Machine Learning Vendor | 27 | Products that generate, classify or decide using a model |
| Infrastructure & Hosting | 25 | Cloud, colocation, managed hosting, CDN |
| Payments & Card Data | 28 | Processors, gateways, acquirers, payment facilitators |
| Staffing & Contingent Workforce | 22 | Agencies, MSPs, umbrella companies, contractor platforms |
| Hardware & Supply Chain | 23 | OEMs, distributors, contract manufacturers |
| Marketing & Advertising Agency | 22 | Creative, media, performance marketing, influencer platforms |
| Reseller & Channel Partner | 21 | Buying through a reseller, VAR or marketplace |
Pick by what the vendor does to your risk, not by the industry you are in. A hospital buying a CRM wants the SaaS set, unless that CRM will hold patient data.
The copy is yours once you create it. Edit the language, retune the severities, archive the clauses you do not care about. Nothing syncs back to the library, so editing cannot break anything.
<Card title="The clause set library" icon="book-open" href="/user-guides/clause-set-library">
What each of the 12 templates covers, the clauses that carry the most weight in each, and what you get inside every copied clause.
</Card>
<Tip>
Copy the library set, run it against three contracts you already know the answers on, and then tune. Starting from working language and adjusting beats starting from a blank page, and it shows you what a well-written reference clause looks like before you write your own.
</Tip>
### Generate a clause set from your own paper
If you have a standard template (your MSA, your DPA, your preferred terms), Guardian can turn it into a clause set.
<Steps>
<Step title="Upload the baseline">
On the Clause Sets page open **Add Clause Set**, choose **Import from Document**, and upload your template as a PDF, Word, or text file. Leave **Document type** on **Detect automatically**, or pick **Baseline contract (one agreement)**. Processing runs in the background; you can leave the page and come back.
</Step>
<Step title="Review what it extracted">
Guardian pulls out clause candidates with exact source text from your template, plus a suggested name, category, severity, and applicable component types. Language it cannot quote verbatim from your document is dropped rather than paraphrased, so what you get back is your own paper.
</Step>
<Step title="Add your fallback tiers">
Each generated clause arrives with a single Tier 1 variant, labeled **Preferred: baseline contract language**. That is a floor, not a playbook: it marks anything that is not your exact template as needing review. Add the tiers you would accept in negotiation before you run the set against a live contract.
</Step>
<Step title="Activate it">
Generated clause sets are created **inactive**, so a half-finished playbook cannot be run against a live contract: an inactive set is not offered when you start a review, and it carries an **Inactive** badge on the Clause Sets page. Once the tiers are in, open the set, click the actions menu beside **Add Clause** and choose **Activate**. **Deactivate** in the same menu takes it back out of use; reviews that already used it keep their results, but they cannot start a new round until you activate it again.
</Step>
</Steps>
If your standard is a clause library or negotiation playbook that states a preferred and a fallback position for each clause, **Import from Document** reads that too, and the positions arrive as tiers.
<Card title="Baseline contract extraction reference" icon="wand-magic-sparkles" href="/user-guides/baseline-contract-extraction">
What extraction proposes, why it drops language it cannot quote verbatim, how a playbook is read, and the tiering you have to finish before the set is usable.
</Card>
### Import a clause set from a spreadsheet
If your standards already live in a spreadsheet, put them in the Coverbase template and upload the file instead of retyping them. One workbook can carry several clause sets, each with full multi-tier variant language.
On the Clause Sets page open **Add Clause Set**, choose **Download Import Template**, fill in the **Clauses** sheet (one row per clause, with rows sharing a **Clause Set** value grouped into one set), then come back and choose **Import from Spreadsheet**.
**Preview import** checks every row before anything is saved and lists any that will not import by spreadsheet row number, and one bad row never blocks the rest. Clauses whose identifier is already in the target set are skipped rather than overwritten, so a stale re-upload cannot replace negotiated language.
<Card title="Spreadsheet import and export reference" icon="file-import" href="/user-guides/clause-set-spreadsheet-import">
Every column explained, the variant format, what happens on re-upload, how to export a set back out, and a troubleshooting table.
</Card>
### Build one by hand
Open **Add Clause Set**, choose **Create Clause Set**, name it, then add reference clauses one at a time with **Add Clause**. This suits a narrow, high-stakes set (an AI addendum standard, say), and rarely a full playbook.
***
## Step 3: Understand a reference clause
Every reference clause is one standard you hold vendors to.
| Field | What it is for |
| - | - |
| **Clause identifier** | Your stable reference, like `SVR-001`. Use it in tickets and email so everyone means the same clause. |
| **Name** | What reviewers see. Use the heading a lawyer would recognize. |
| **Severity** | Low, Medium, High, or Critical. Drives triage order and grouping, but does *not* change the verdict. Reserve Critical for clauses that would block a signature. |
| **Rationale** | Why the clause matters. Written for humans; it is the context a reviewer needs when they hit a deviation. |
| **Guidance** | Written for the AI. This is what tells the matcher how to find and evaluate the clause. See below. |
| **Applicable component types** | Which parts of a contract this clause should be found in. Leave empty to apply everywhere. |
| **Variants** | Your acceptability tiers, covered in the next step. |
### Writing guidance the matcher can use
Guidance is the instruction the model reads when hunting for vendor language. The library clauses are worth copying as a format. This is the shape that works, from the packaged Limitation of Liability clause:
```text Guidance theme={null}
Aliases:
- Limitation of Liability
- Liability Cap
- Limitations on Liability
- Maximum Liability
Typical contract types:
- MSA
- SaaS Agreement
- Services Agreement
Extraction signals:
- ALL CAPS BLOCKS containing 'IN NO EVENT'
- phrases: 'aggregate liability', 'total liability', 'fees paid'
- multipliers: '1x', '2x', 'twelve (12) months'
- carve-outs: 'except for', 'notwithstanding', 'shall not apply to'
Common deviations:
- Cap is unspecified or 'unlimited'
- Cap is asymmetric (one party capped, other uncapped)
- Carve-outs are too broad
- Missing carve-outs for IP indemnity, data breach, confidentiality
```
Four sections: **aliases** the clause hides under, **contract types** it appears in, **extraction signals** (distinctive phrases, formatting quirks, numbers), and **common deviations** you have seen. You do not need all four on every clause, but aliases and signals make the biggest difference.
***
## Step 4: Write your risk-tier variants
This is the step that determines whether Contract Guardian is useful or noisy.
A **variant** is one version of the clause language at one level of acceptability, on a scale of 1 to 5. Coverbase matches the vendor's actual language to the closest variant, and the tier of that variant becomes the verdict:
| Risk tier | Meaning | Resulting clause state |
| - | - | - |
| **1** | Your preferred language | **Conforming** |
| **2** | Acceptable without escalation | **Conforming** |
| **3** | Negotiable; a reviewer should look | **Needs review** |
| **4** | Materially worse than standard | **Non-conforming** |
| **5** | Unacceptable | **Non-conforming** |
Two more rules apply on top of the tier mapping:
* **Low-confidence matches never auto-pass.** If the matcher is not confident enough in the match, the clause is set to **Needs review** regardless of which variant it landed on.
* **Language found outside its scope is escalated.** If a clause turns up in a component it was not scoped to, or if the language materially conflicts with the matched variant, the clause goes to **Needs review** rather than being scored.
### How many tiers do you need?
You do **not** need all five on every clause. Start with three and add as you learn:
<Steps>
<Step title="Tier 1: your ask">
The language you would put in your own paper. If you generated the set from a baseline contract, this is already filled in.
</Step>
<Step title="Tier 3: your fallback">
What you would sign after a round of negotiation without escalating. Most real vendor paper lands on this tier, and it is what routes a clause to a person for review.
</Step>
<Step title="Tier 5: your walkaway">
Language you will not accept. Writing it down turns "this feels bad" into a consistent, defensible verdict.
</Step>
</Steps>
Add tiers 2 and 4 once you have seen enough contracts to know where the intermediate lines sit.
<Warning>
A clause with only a Tier 1 variant flags nearly everything, because almost no vendor's paper matches your template word for word. That is the most common cause of a noisy first review, and the usual state of a freshly generated baseline clause set. Add a fallback tier before judging the false-positive rate.
</Warning>
### Label your variants like a negotiator
The label shows up next to the verdict, so make it say what the tier is. From the library set:
* Tier 1: *"Vendor-favorable: 1x fees, 12 month lookback, broad consequential carve-out"*
* Tier 3: *"Balanced: 2x fees with carve-outs for confidentiality and data breach"*
* Tier 5: *"Unacceptable: liability disclaimed in full"*
A reviewer reading *"Balanced: 2x fees with carve-outs"* knows what they are looking at. A reviewer reading *"Tier 3"* has to go find out.
***
## Step 5: Scope clauses to contract components
Guardian first detects the **components** inside your linked documents (the MSA, the DPA, the order form, the SLA, the NDA, the amendment, the SCCs, the AI addendum, and so on), then evaluates each reference clause only where it belongs.
Set **Applicable component types** on each reference clause accordingly. A data-processing standard belongs on the DPA and MSA. A pricing standard belongs on the order form. Governing law belongs everywhere, so leave it unscoped.
Scope decides what a *missing* clause means:
| Situation | Result |
| - | - |
| The clause's component is present, but no matching language found | **Missing**: a genuine gap in the vendor's paper |
| The clause's component is not in this contract at all | **Not applicable**: correctly ignored |
| A component could not be classified, so the answer is uncertain | **Needs review**: flagged for a human |
<Tip>
Unscoped clauses (empty component types) are evaluated against everything, so a missing one always reads as **Missing**. Scope the clauses that only apply to one kind of paper, and your Missing list stays meaningful.
</Tip>
***
## Step 6: Run a review
A review runs in five steps, shown in the rail at the top of the page. You move through them in order, and the rail says where you are.
<Frame>
<img alt="Review step rail: choose documents, analyze the contract, review results, summary, communicate" />
</Frame>
| Step | What happens |
| - | - |
| **1. Choose documents** | You choose the standards to check against and the documents to read. |
| **2. Analyze the contract** | Coverbase reads the documents and matches every reference clause. |
| **3. Review results** | You see the counts and pick what to work. |
| **4. Summary** | You decide each clause, one at a time. |
| **5. Communicate** | You draft the follow-up and export the redlined Word file. |
Only active clause sets are offered when you start a review. Sets you create by hand, copy from the library, or import from a spreadsheet are active from the start; generated sets are not until you choose **Activate** in the set's actions menu. Open the contract, go to the **Review** tab, and choose **Start review**.
### Select documents
<Frame>
<img alt="Select documents step showing suggested standards, other standards, documents to analyze, reviewer, and job estimate" />
</Frame>
Four things sit on this step.
**Suggested for this contract** lists the clause sets that cover components this contract has. **Other standards** lists the rest, and tells you their clauses will mostly come back as not applicable. Pick at least one.
**Documents to analyze** lists every live document on the contract. All of them are selected. Clear the checkbox on any document you want left out, and the review skips it.
Each document shows its type, when it was uploaded, and who uploaded it, so you can tell two similar files apart before you commit to reading both.
<Note>
Start from everything selected and take documents out, rather than adding them one at a time. A review that reads a subset can miss a clause that was in the file.
</Note>
**Reviewer** puts the review in someone's work queue. You can leave it unassigned.
**Job estimate** tells you how many clauses, standards, and documents the run covers once you have picked a standard. Only in-force language is checked, so superseded clauses are excluded.
If the contract has no documents yet, this step says so and links you to the Documents tab. The start button stays disabled until there is something to read.
### Analyze the contract
Coverbase extracts the text, detects components, and matches every reference clause across the documents you selected. If the vendor has a completed assessment, it then layers that evidence onto each flagged clause.
A progress indicator runs while it works. You can navigate away and come back.
<Note>
Each run takes a **snapshot** of the clause set at the moment it starts. Editing a reference clause mid-run does not change the verdicts of a review already in flight, and old runs stay readable against the standard they were judged by.
</Note>
### Start another review
One review runs at a time, but a finished review does not lock the contract. **Start a new review** sits in the header on every step after the analysis. Use it when a run read the wrong documents, when you picked the wrong standard, or when new paper has landed since the last run.
Starting a new review takes you back to step 1 with the pickers open. Previous runs stay readable.
***
## Step 7: Work the results
The last three steps of the rail are yours: read the results, decide each clause, then send what you decided.
### Review results
<Frame>
<img alt="Review results step reading 4 clauses require review, with needs a decision, clause not found, clause fulfilled and not applicable cards above a table of clauses" />
</Frame>
The step opens on how many clauses need you, and four cards that sort every clause the run read:
| Card | What is in it |
| - | - |
| **Needs a decision** | Clauses that came back Non-conforming or Needs review. |
| **Clause not found** | Clauses whose component is in the contract but whose language is not (Missing). |
| **Clause fulfilled** | Clauses that conform, or whose risk you have already accepted. |
| **Not applicable** | Clauses whose component is not in this contract. |
Click a card to filter the **Review clauses** table to it. The table gives each clause's clause set, category, status, severity, and confidence. Search it, narrow it to one clause set, or click a row to open that clause. **Review N clauses** walks the clauses that need a decision or were not found, most severe first. **Show all N** walks every clause.
The contract's **Review** tab keeps the latest run as a list, for triage without the step-by-step flow.
<Frame>
<img alt="Review tab listing clauses grouped by severity, each with its state, above search, filter and follow-up draft controls" />
</Frame>
The list opens on **All N results**. Switch to **N flagged** to see only the clauses that came back Non-conforming, Needs review, or Missing and have not been triaged yet.
#### What each row tells you
Each row shows the clause's state and, when the vendor has a completed assessment, the suggested disposition. Click a row to open the clause in the review console, where the clause card carries the rest:
| Element | What it means |
| - | - |
| **State** | Conforming, Needs review, Non-conforming, Missing, or Not applicable |
| **Matched variant** | Which of your tiers the vendor's language landed on |
| **Confidence** | How sure the matcher was. Low confidence forces Needs review |
| **Source** | The document and page the language came from |
| **AI analysis** | A few bullets on why it landed where it did |
| **Assessment insights** | A suggested disposition drawn from the vendor's latest completed assessment |
Group by **status**, **severity**, or **confidence**, sort by severity, and search by clause name. On a 40-clause set against a heavily negotiated MSA, grouping by severity and working top-down is the fastest path.
#### Assessment insights
When the vendor has a completed assessment, Guardian cross-references the clause against that evidence and suggests a disposition: **No action**, **Revise language**, **Add clause**, or **Escalate**, with citations back into the assessment.
A weak audit-rights clause matters more when the vendor's assessment already shows control gaps, and less when they hold a clean SOC 2. The suggestion is input for your judgment rather than a verdict, and it sits separately from the clause state.
#### Triage every flag
Triaging is the review. Marking a clause removes it from the flagged list while leaving the system's verdict visible, so the record shows both what the AI concluded and what you decided.
<CardGroup>
<Card title="No action" icon="check">
Reviewed and fine as written. The most common outcome on Needs-review clauses once a human reads them.
</Card>
<Card title="Accepted risk" icon="shield-halved">
Materially worse than your standard, and you are signing anyway. This is your audit trail for a conscious exception.
</Card>
<Card title="False positive" icon="circle-xmark">
The matcher got it wrong. Feed these back into the reference clause's guidance so the next review does better.
</Card>
<Card title="Create finding" icon="flag">
Escalate to a tracked finding with an owner and a due date. Triage flips to **Action created** automatically, and the finding stays linked to the clauses that produced it.
</Card>
</CardGroup>
Triage a clause from the menu at the end of its row (**Mark no action**, **Mark accepted risk**, **Mark false positive**, or **Create Finding**). Select several clauses at once to **Triage** them together or **Bulk Create Findings** covering all of them, which suits a case where one negotiation thread touches liability, indemnity, and insurance together.
### Decide
The fourth step, labeled **Summary** on the rail, gives you one clause at a time in a three-pane console.
<Frame>
<img alt="Three-pane decide console showing playbook positions, suggested redline, decision options, and the source document" />
</Frame>
| Pane | What it holds |
| - | - |
| **Left** | Your playbook positions for this clause, with the guidance you wrote. Select a position to redraft the redline against it. |
| **Middle** | The suggested redline, with your decision underneath. |
| **Right** | The source document, and the clause card with state, severity, confidence, and the AI analysis. |
Drag the dividers to resize the panes. Your widths are remembered for the next clause and the next review.
Four decisions sit under the redline. Press **1** to **4** to pick one, or click it.
| Key | Decision | Effect |
| - | - | - |
| **1** | Accept as-is | Closes the clause. |
| **2** | Flag for the vendor | Adds it to the follow-up you send at the end. |
| **3** | Accept the risk | Records the exception with an owner and an expiry date. |
| **4** | Not applicable | Marks the standard as not relevant to this contract. |
**Save** (or **Enter**) records the decision and moves to the next clause. **Skip for now** moves on without recording one. **Previous clause** and **Next clause** sit in the header with your position in the queue between them, and the up and down arrow keys do the same.
**Show every clause** switches the queue between the clauses that need you and all of them, including what conformed.
### Communicate
<Frame>
<img alt="Communicate step showing counts of decisions, the generated follow-up draft, and the redlined Word file button" />
</Frame>
Four counts at the top say what you decided: **Accepted as-is**, **Flagged for vendor**, **Risk accepted**, and **Not applicable**. **Back to results** returns to the queue.
The follow-up draft is built from the clauses you flagged, quoting your standard and the vendor's language. Tick or untick clauses to change what it covers, then **Regenerate**. Nothing sends on its own:
* **Copy to clipboard** copies the draft for your own email.
* **Send email** opens the Coverbase email composer with the draft in it. It is addressed to the vendor's contacts, copies the contract's owners and watchers and the vendor's owners, analysts and watchers, and attaches the redlined Word file when the review has one. Check it and send it from there.
* **Create Finding from selected** escalates the ticked clauses to a finding, when findings are on for your organization.
#### Download the redlined Word file
If the review read a Word document, choose **Download redlined Word file** next to the draft. You get the contract's own `.docx` back with:
* The contract's wording struck through and your playbook's wording inserted, as tracked changes
* One comment per clause carrying the clause name, the reasoning, and the language you are asking for
Open it in Word and the changes appear in the Review ribbon your vendor already uses. Send it as an attachment, or accept and reject changes yourself first.
<Note>
Every clause goes into the file except the ones you marked **Not applicable**. Accepting the risk still sends the ask: accepting a deviation internally is not the same as withdrawing it from the vendor.
</Note>
A clause whose wording already matches your standard produces no tracked change. A clause the export cannot locate in the document is named in a comment rather than dropped silently.
<Note>
The export needs a Word document. A contract that only ever arrived as a PDF has nothing to mark up, and the button tells you so when you click it.
</Note>
#### When nothing was flagged
<Frame>
<img alt="Communicate step with no flagged clauses, offering to start a new review" />
</Frame>
If no clause was flagged, there is nothing to draft. The step says so and offers **Start a new review** instead. That is usually the right move when a run read the wrong documents.
***
## Step 8: Iterate
Your first review is a draft of your playbook, not a verdict on the vendor.
<AccordionGroup>
<Accordion title="Too many flags" icon="triangle-exclamation">
Almost always missing middle tiers. If your clauses only have Tier 1 and Tier 5, everything realistic lands in between and gets escalated. Add Tier 3 fallback language for the clauses generating the most noise.
</Accordion>
<Accordion title="Clauses come back Missing that are plainly in the contract" icon="magnifying-glass">
Either the component scope is wrong (the clause is scoped to DPA but the language lives in the MSA), or the guidance does not name the alias the vendor used. Fix the guidance first; it is the cheaper change.
</Accordion>
<Accordion title="Everything lands on Needs review with low confidence" icon="gauge-low">
Usually a text-quality problem. Scanned or image-only PDFs give the matcher little to work with. Re-upload text-based versions where you can.
</Accordion>
<Accordion title="Rerun after you change something" icon="arrows-rotate">
Reviews do not re-run themselves when you edit a clause set or add a document. Use **Start a new review** from the flow header, or **Rerun** from the run actions menu on the Review tab. Either one snapshots your current clause set, and starting a new review lets you change the documents as well as the standard.
</Accordion>
<Accordion title="Reference clauses are versioned" icon="clock-rotate-left">
Editing a reference clause creates a new version and marks it current. Older reviews still show the version they ran against, and you can open a clause's version history at any time. Edit freely; the record is kept.
</Accordion>
</AccordionGroup>
<Tip>
Track your false-positive triages for the first month. Each one points at a specific reference clause whose guidance or variants need work, and fixing them is what makes a clause set reliable.
</Tip>
***
## A workable rollout
<Steps>
<Step title="Week 1: copy and calibrate">
Copy the **Enterprise SaaS Subscription** set from the library. Run it against three executed contracts you already know well. Compare Guardian's verdicts to your own and note every disagreement.
</Step>
<Step title="Week 2: tune the noisy clauses">
Fix the five clauses that produced the most disagreement: add fallback tiers, sharpen guidance, correct component scope. Ignore the clauses that already work.
</Step>
<Step title="Week 3: add your own paper">
Upload your template MSA as a baseline contract to generate a second clause set reflecting your own standard, then merge the best of both into the set you will run day to day.
</Step>
<Step title="Week 4: put it in the workflow">
Start assigning reviewers on new contracts so reviews land in work queues, and make triage the definition of done for legal review.
</Step>
</Steps>
## What's next
<CardGroup>
<Card title="Document Insights guide" icon="file-magnifying-glass" href="/user-guides/document-insights">
The field-extraction half: what to define, and when to use Extract vs Synthesize.
</Card>
<Card title="Analyst and reviewer guide" icon="user-check" href="/user-guides/analyst-reviewer">
How contracts fit into the wider assessment and findings workflow.
</Card>
</CardGroup>
# Contract intake and approval
Source: https://docs.coverbase.com/user-guides/contract-intake-and-approval
Raise a contract request from a vendor, confirm what the AI read off the draft, route it through your approval chain, and send the approved agreement to DocuSign.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers a contract from the first request to the filing of the signed copy. For the screens you work in afterwards, see the [Contracts workspace guide](/user-guides/contracts-workspace). For the DocuSign connection itself, see the [DocuSign integration guide](/integrations/guides/docusign).
</Info>
A new contract goes through four stages: somebody raises a request, a person confirms the values read off the draft, the request walks an approval chain, and the approved agreement goes out for signature. The contract's **Workflow** tab lays them out as numbered steps in that order, and a contract cannot skip one.
<Note>
**Contracts that predate this flow are unaffected.** Every historical and bulk-imported contract sits in **Draft** and stays there. Nothing about a draft implies it is unsigned. If you are migrating a back catalog, keep using [bulk import](/import); it does not route anything through approvals.
</Note>
## The four stages
<Steps>
<Step title="Raise the request">
From the vendor's **Contracts** tab, click **New Contract**. Fill in what you know and attach the draft agreement.
</Step>
<Step title="Confirm the metadata">
Coverbase reads the draft and fills in what it can. Open the contract's **Workflow** tab and confirm the values under **Metadata sign-off**. The request cannot proceed until somebody does.
</Step>
<Step title="Approve">
Click **Submit for approval** on the **Approval chain** step. The request enters the chain your organization configured, and each approver is emailed in turn and records a decision.
</Step>
<Step title="Send for signature">
Once the chain clears, the **Signature** step of the Workflow tab offers the send. The signed copy comes back and is filed on the same contract.
</Step>
</Steps>
The button beside **Actions** in the contract header names the step the contract is waiting on (**Submit for approval**, **View approval**, **Send for signature**, or **Track signature**) and opens the Workflow tab. While a clause review has flagged clauses nobody has triaged, it reads **Continue clause review** instead.
## Raising a request
Start from the vendor, not the contracts list. The vendor's **Contracts** tab already knows which vendor you mean, and it shows what else you hold with them. That is usually what tells you whether this is a new agreement or an amendment.
Click **New Contract** and fill in:
| Field | What it is |
| - | - |
| **Contract Name** | What people will call this agreement. |
| **Services** | Optional. The services the contract covers. |
| **Status** | The lifecycle stage the contract starts in. |
| **Hold for my review** | Optional. Keeps the contract out of approval routing while you finish it. See below. |
| **Link Existing Documents** | Optional. Contract documents already on the vendor, such as the MSA an order form hangs off. |
| **Upload New Documents** | Optional. The pre-execution draft. |
The form does not ask for the type, value, or dates. Coverbase reads those off the attached draft, and you check or fill them in afterwards on the **Terms** card of the contract's **Overview** tab. You can attach more documents later from the contract's **Documents** tab.
<Tip>
**Link the governing paper now, not later.** If this is an order form or an amendment, link the MSA it hangs off under **Link Existing Documents**. An order form with no MSA behind it reads as a standalone commitment in every report that follows.
</Tip>
### Starting a draft nobody is told about
Most requests are raised from a document you already have in front of you, and you can fill the record in one sitting. Some are not. When you are raising the record before the terms are settled, tick **Hold for my review** on the create form.
<Frame>
<img alt="Needs Attention card with a Held for intake review line and a Release for routing button" />
</Frame>
While the hold is on:
* **No approver is emailed.** Approval routing is what puts this record in front of other people, and it cannot start.
* **It cannot be submitted for approval.** The attempt is refused, not merely hidden, so the hold cannot be worked around by a direct link.
* **You can still edit everything.** That is the point: finish entering the terms, attach the draft, fix the dates.
The **Needs Attention** card on the contract's **Overview** tab says it is held, and so does the Workflow tab. Click **Release for routing** in **Needs Attention** when the record is ready to be looked at. Approval routing is then available in the normal way, and the release is recorded in the contract's activity trail with who did it.
<Note>
**Releasing says the record is ready to read, not that it is approved.** It is a separate statement from confirming the metadata, which still happens afterwards. Any colleague who can edit contracts can release the hold, so a request does not stall when the person who raised it is away.
</Note>
<Tip>
A held contract still shows in the contracts list. Filter on **Held For Intake Review** is `Yes` to find drafts that have been sitting unreleased.
</Tip>
## Asking a colleague to look first
The first step on the **Workflow** tab is **Reviews**. Click **Request review** to ask a named colleague or a user group for a decision on the draft, with a note saying what to look at. Each review records its outcome, and the step counts how many have been approved.
Reviews are optional. They do not hold up submission or the approval chain on their own, so a request can be submitted with a review still open. Use them when somebody should read the draft before approvers are asked, and use the approval policy for the decisions that must be recorded before the contract can move. Reviews work the same way everywhere in Coverbase; see [Reviews, approvals and gates](/user-guides/reviews-and-approvals).
## Confirming the metadata
Coverbase analyzes the attached draft and fills in the values it can read: dates, amounts, notice periods, term length. Scanned PDFs are put through OCR first, so a photographed signature page is read the same as a native one.
**Everything the AI writes is a draft value.** It is never treated as confirmed, and a contract whose values nobody has confirmed cannot be submitted for approval.
Open the contract's **Workflow** tab. The **Metadata sign-off** step shows:
* Which required values are still empty. The card lists them by name, and submission stays blocked until each has a value.
* Whether anybody has confirmed the set, and who.
<Frame>
<img alt="Metadata sign-off card listing the required values that are still empty" />
</Frame>
Fix anything that is wrong in **Terms** on the Overview, then click **Confirm metadata**. Coverbase records who confirmed it and when.
<Warning>
**Editing a confirmed value clears the sign-off.** If you change the total value, the dates, the type, or the vendor after confirming, the confirmation is withdrawn and somebody has to confirm again. Approvers decide on the values they were shown, so a request that changed after the sign-off has to be confirmed again.
</Warning>
### Where a value came from
Each field records whether it was entered by a person or suggested by the AI. The **Metadata sign-off** step marks the source beside each value, and the same marker appears on the **Overview** tab. A reviewer can see which numbers a person typed and which came off the paper.
## The approval chain
### Setting up policies
Approval policies live under **Configuration → Contract Approvals**, in the **Contracts** group. Search the Configuration page for *approval* to find it. Reading them needs permission to read organization settings, and editing them needs permission to change organization settings. Being able to read contracts is not enough for either: the list names every approver and every value threshold in your organization, and it is not tied to any one contract.
Until there is at least one policy, the page says so, and every contract submitted for approval is approved on the spot with no approver.
<Frame>
<img alt="Contract approval settings with a warning that no policy is configured" />
</Frame>
**Add approval policy** opens the editor. Give it a name, say which contracts it covers, and add a row for each decision.
| Field | What it does |
| - | - |
| **Contract types** | Only applies to the types listed. Empty covers every type. |
| **Minimum total value** | Only applies at or above this amount. Empty covers any value. |
| **Use as the default policy** | Runs when no other policy matches. |
| **Send for signature on approval** | Sends the agreement out automatically once the last approver signs off. See [Sending automatically](#sending-automatically). |
| **Approval steps** | One row per decision: the order number, a name, and who decides. |
<Frame>
<img alt="Approval policy editor with name, contract types, value floor, two toggles and two approval steps" />
</Frame>
Saved policies read back as a ladder, which shows the order a contract will go through.
<Frame>
<img alt="Two approval policies listed with their conditions and step chains" />
</Frame>
<Note>
**Editing a policy does not change an approval already running.** A contract copies each step's name and approver when it is submitted. Changing the policy afterwards does not change a decision already recorded.
</Note>
### How a chain is chosen
Your organization configures approval policies. Each policy has conditions and an ordered list of steps.
When you submit, Coverbase picks the policy that fits, most specific first: a policy naming your contract's type beats one that names none, and among equals the higher value floor wins. **Default** breaks whatever tie is left.
You cannot choose the policy yourself. Submission takes no arguments, and the conditions above are the only thing that decides. Otherwise a requester could pick the shortest chain.
### How steps work
Each step names who decides:
* **A named person.** That user, and nobody else.
* **A user group.** Any active member of the group may decide, and Coverbase records which one did.
* **The contract owner** or **the vendor owner.** Resolved when you submit, from whoever holds that role at that moment.
Steps are numbered. **Steps sharing a number decide together**, and the chain does not advance until all of them have. Increasing numbers run one after another.
Two steps sharing a number cannot name the same approver, and the editor refuses to save that. One person clearing both would count as two approvals while being one decision. This applies to user groups too: the same group twice at one number is refused, though two different groups at one number is fine and is the normal way to ask legal and security together.
<Note>
**Every policy needs at least one step.** A policy that matches contracts and then approves all of them has the same effect as no policy, while looking in settings like routing is configured. The editor will not save one.
**A step that resolves to nobody refuses the whole submission.** Coverbase does not skip the step and run the rest, because a chain missing a rung still reports itself as approved. Two ways a step reaches nobody:
* The policy asks for the contract owner or the vendor owner, and there is none.
* The policy names a user group that has no active members. An empty group would open a step that nobody can approve and that sends no mail, leaving the request stuck until somebody withdrew it.
The refusal names the step it could not fill. Give the contract an owner, add somebody to the group, or point the policy at approvers it can reach, then submit again.
A contract submitted when your org has configured no policy at all is approved immediately, and its **Approval chain** step says so rather than showing a bare **Approved** badge. If that is not what you expect, configure a policy.
</Note>
### Submitting
On the **Workflow** tab, click **Submit for approval** in the **Approval chain** step. Until the metadata is confirmed and every required value has one, the button is disabled and the step says what is still needed: a value to add under **Terms** on the Overview, the sign-off itself, or an intake hold to release.
Coverbase emails the approvers on the first step. Later steps are emailed as the chain reaches them, so nobody is asked before it is their turn.
### Deciding
An approver opens the contract's **Workflow** tab and sees **Approve** and **Reject** on the chain step waiting on them. The buttons appear only for the person being asked, so an approver who is not on this step sees the chain but no controls.
<Note>
**Approving does not require permission to edit the contract.** An approver is frequently somebody who would never otherwise edit a contract record, such as a finance reviewer signing off on spend. Being named on the step is what authorizes the decision.
</Note>
<Frame>
<img alt="Approval chain with one approved step and one active step carrying approve and reject buttons" />
</Frame>
A comment can go with either decision and is shown on the step afterwards.
**A rejection ends the round.** Every step after it is canceled rather than left open, and the requester is emailed with the reviewer's comment. Fix what was raised, confirm the metadata again, and submit. That starts a new round; the previous round's decisions stay readable.
### Withdrawing
The requester can click **Withdraw** while a request is in approval. The open steps are canceled and the contract returns to draft.
## Who gets emailed
| Event | Who hears about it |
| - | - |
| A step opens | The person or group that step is waiting on, and only them. |
| The chain clears | The requester, the contract owners, and the watchers. |
| A step rejects | The requester, the contract owners, and the watchers, with the comment. |
Date-based reminders, such as an approaching expiry or notice deadline, are configured separately. See [Contract dates and reminders](/user-guides/contract-dates-and-reminders).
## Sending for signature
Once the chain clears, the **Signature** step of the Workflow tab offers the send. Before then the button is disabled and the step says why.
Which send you see depends on how your organization signs. Organizations on Coverbase's own e-signature see a **Signature** card that raises the envelope inside Coverbase; see the [signature overview](/user-guides/signature-overview). Organizations that sign in DocuSign see **DocuSign Execution** with **Send to DocuSign**, described below.
You need a connected DocuSign account. See [connecting DocuSign](/integrations/guides/docusign#connecting-your-account) if you have not done that.
On **Send to DocuSign** you choose:
* **The document to send.** Only a document already attached to this contract can be sent. This is the approved draft, not a fresh upload.
* **Recipients**, each with a name, an email, a role, and an order.
* **Subject and message** for the DocuSign email.
<Frame>
<img alt="Send to DocuSign dialog with a document picker, recipient rows, subject and message" />
</Frame>
| Role | What it means |
| - | - |
| **Signer** | Signs the agreement. |
| **CC** | Receives a copy. Never asked to sign. |
**Order controls routing.** Recipients sharing an order are asked together. Increasing orders are asked one after another, which is how you route the counterparty first and your own signatory second.
<Tip>
Give the vendor signer order `1` and your own authorized signatory order `2`. The envelope reaches your side only once the counterparty has signed.
</Tip>
### Sending automatically
A policy with **Send for signature on approval** sends the agreement as soon as its last approver signs off, with nobody at a screen.
Coverbase needs to know who signs before the approval finishes. While the contract is still moving through its chain, **Set up automatic send** on the DocuSign Execution card asks the same questions the Send dialog asks: which document, who signs, in what order, and who is copied.
<Frame>
<img alt="Automatic send dialog with a document picker, two recipients and an email subject" />
</Frame>
Once it is set up, the DocuSign Execution card says what is about to happen.
<Frame>
<img alt="DocuSign Execution card noting the contract goes out to two recipients automatically once approved" />
</Frame>
The envelope goes out **as the person who set up the automatic send**, using the DocuSign connection they made. They do not have to be at a screen when it happens, but they do have to have connected: see [Connecting DocuSign](/integrations/guides/docusign).
<Note>
**Whoever last saved the plan is who it is sent as.** Anybody who can edit the contract can change the recipient list, and doing so also moves the send to their own Docusign account. Nobody can send an agreement under somebody else's name.
</Note>
<Note>
**A send that does not go out never undoes an approval.** If DocuSign is unreachable, or the plan author's connection has lapsed, the contract stays approved and the plan stays on it. The DocuSign Execution card says the automatic send did not go out, and **Send to DocuSign** remains available to send it by hand. The one exception is a send that got as far as DocuSign and lost its answer, covered under [When a send loses its answer](#when-a-send-loses-its-answer).
</Note>
<Frame>
<img alt="DocuSign Execution card warning that the automatic send did not go out" />
</Frame>
Clearing the recipient list and saving turns the automatic send back off. You can do that at any point while the contract is still in its chain, and until the send starts.
Once the agreement has gone out, Coverbase refuses the change and tells you the envelope is already with your signers. Turning the plan off at that point would report the send as canceled while a copy sat in front of the counterparty. To stop an envelope that is already out, void it in DocuSign and choose **Sync status**.
### Tracking the envelope
The **DocuSign Execution** card shows every DocuSign envelope raised on this contract, each recipient's state, and when the status was last read from DocuSign.
| Envelope status | What it means |
| - | - |
| **Draft** | Created in Coverbase, not yet accepted by DocuSign. |
| **Sent** | Out with the first routing step. |
| **Delivered** | Everybody in the current step has opened it. Nobody has signed. |
| **Partially signed** | At least one signer has signed, at least one has not. |
| **Completed** | Everybody has signed. |
| **Declined** | A recipient refused. The contract returns to approved. |
| **Voided** | Canceled in DocuSign. The contract returns to approved. |
| **Expired** | DocuSign's own expiry ran out before everybody signed. The contract returns to approved. |
Every ending but **Completed** returns the contract to approved. It is ready to send again without anybody editing a record by hand.
<Frame>
<img alt="Envelope card showing two signers and a CC recipient with individual statuses" />
</Frame>
Status arrives on its own. DocuSign notifies Coverbase as the envelope moves, and a scheduled pass re-reads every in-flight envelope in case a notification was missed. **Sync status** on the envelope reads it back immediately, for when you are watching a signature land and do not want to wait.
### When a send loses its answer
Very occasionally a send reaches DocuSign and the reply never comes back. Coverbase cannot tell that apart from DocuSign refusing the send outright, so it assumes the riskier of the two: the envelope may be out there with your signers. The contract is held as sent for signature, the envelope shows as failed, and the DocuSign Execution card explains what happened instead of offering **Sync status**, which has nothing to ask about.
<Frame>
<img alt="Envelope card marked failed, with a warning that Docusign never confirmed the send and an Abandon send button" />
</Frame>
Only a person can settle it. Open DocuSign and look for the envelope:
<Steps>
<Step title="Nothing is there">
Choose **Abandon send** on the envelope. The contract returns to approved and can be sent again. The button appears once: an envelope that has already been abandoned shows no action, so a second click cannot free a contract whose retry is out with its signers.
</Step>
<Step title="The envelope is there">
Leave it. It is a real envelope and it will report its own status. If you do not want it signed, void it in DocuSign and choose **Sync status** so Coverbase picks the void up, which returns the contract to approved.
</Step>
</Steps>
<Warning>
**Do not abandon an envelope you can still see in DocuSign.** Abandoning says the agreement never went out. Doing that while a copy sits in front of your signers frees the contract for a second send, and you end up with two signed copies of one agreement. Coverbase refuses **Abandon send** on any envelope DocuSign acknowledged.
</Warning>
### The executed copy
When an envelope completes, Coverbase downloads the signed PDF and the DocuSign certificate of completion and attaches both to the contract. The unsigned draft is kept rather than replaced. The record still shows what was sent out.
<Warning>
**A signed copy that differs from the approved draft is flagged, not applied.** Coverbase compares the returned text with the draft the approvers read, and the envelope is marked for review whenever either check fires: the paper grew or shrank by more than a signature block can account for, or a figure the draft stated no longer appears anywhere in the signed copy. The second check catches a term rewritten in place: net 30 becoming net 90 does not change the length, so only the missing figure reveals it. When an envelope is flagged the contract's metadata is left alone and somebody has to look at it.
</Warning>
<Frame>
<img alt="Envelope card with a warning that the signed copy differs from the approved draft" />
</Frame>
Everything is recorded on the contract's **Activity** tab: the submission, each review and decision, the comments, the status changes, the send, and the filing of the executed copy.
## The vendor's contract overview
The vendor's **Contracts** tab shows every contract you hold with that vendor in the same table as the contracts list, with the same columns and **Preview**.
Above the list:
* **Committed value** across active contracts. Contracts that bill on usage are counted at their committed floor and reported separately, because a usage forecast added to signed commitments would give a total that is part estimate.
* **Needs attention.** Contracts with a notice deadline or expiry inside the next ninety days, soonest first, plus any whose required details are still incomplete. An overdue notice deadline is shown in red and stays in the list.
<Frame>
<img alt="Needs attention panel listing an overdue notice, two approaching deadlines, and a contract with incomplete details" />
</Frame>
**Actions → Export as Excel** exports the vendor's contract list. The export respects the filters and columns you are looking at.
## Related
<CardGroup>
<Card title="DocuSign integration" icon="file-signature" href="/integrations/guides/docusign">
Connecting your account, anchor tags, and what lives in your DocuSign tenant.
</Card>
<Card title="Contracts workspace" icon="folder-open" href="/user-guides/contracts-workspace">
The list page and the contract record you work in afterwards.
</Card>
<Card title="Contract dates and reminders" icon="calendar-check" href="/user-guides/contract-dates-and-reminders">
Notice windows, renewal deadlines, and who gets reminded.
</Card>
<Card title="Reviews and approvals" icon="user-check" href="/user-guides/reviews-and-approvals">
How approvals work elsewhere in Coverbase.
</Card>
</CardGroup>
# Negotiation rounds
Source: https://docs.coverbase.com/user-guides/contract-negotiation-rounds
Upload the marked-up contract a vendor sends back, see what they changed, which of your asks they accepted, and what they edited without being asked, without starting the clause review over.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It picks up where the [Contract Guardian guide](/user-guides/contract-guardian) ends: you have run a clause review, decided the flagged clauses, and sent the vendor a redline. For how those asks are written and sent, read that guide first.
</Info>
A contract review does not end when you send the redline. The vendor answers, usually weeks later, usually with a marked-up document, and you have three questions:
* **What did they change?**
* **Did they give me what I asked for?**
* **What is still open?**
A round answers all three against the review you already ran. You do not start a second review, and you do not lose the verdicts you recorded the first time.
## What a round is
One exchange: you send asks, the vendor returns a document, Coverbase reads it against what you asked for.
| | |
| - | - |
| **Round 1** | Your first clause review. You decide the flagged clauses and send a redline. |
| **Round 2** | You upload what the vendor sent back. Coverbase compares it to round 1 and tells you what moved. |
| **Round 3+** | The same again. Contracts that go three or four rounds are normal, and each one only asks about what changed. |
Your decisions carry. A clause whose language the vendor did not touch keeps the verdict you gave it, and the round says which round you gave it in. Anything the vendor edited comes back to you, whatever you decided last time, because a decision about the old language is not a decision about the new.
## Before you start
<Steps>
<Step title="Have a completed round">
You need a clause review on this contract with at least one ask sent to the vendor. If nothing has been sent yet, there is nothing to compare against, so run the review first.
</Step>
<Step title="Have the vendor's document">
A PDF or Word file of the contract as the vendor returned it. Their cover email or response letter is useful too; you can upload both.
</Step>
<Step title="Check your permissions">
Starting a round needs the same contract-update permission as starting a review.
</Step>
</Steps>
<Note>
You do not have to finish reviewing round 1 before starting round 2. If the vendor comes back early, upload their document. Clauses you had not decided yet stay undecided and carry into the new round.
</Note>
## Step 1: Upload what the vendor sent back
While a round is out with the vendor, the review page says so, and the upload sits on that same banner. **Upload vendor response** is also in the review page header, so you do not have to remember which screen you were on.
<Frame>
<img alt="Callout reading round 1 sent, 8 asks outstanding, with an upload vendor response button" />
</Frame>
Add the vendor's file on the contract's **Documents** tab, the same way you add any other contract document. Coverbase reads it against the documents already on the contract and asks you to confirm what it does before anything is saved. The question that matters here is **is this a new version of a document already on the contract, or a new document alongside it?**
* **Replaces** marks it as a new version. The superseded text stops being reviewed.
* **Adds to the contract**, **Attaches**, or **New on its own** keeps it alongside the others, such as an amendment, a cover letter, or a side agreement.
Getting that wrong costs you: a replacement recorded as an addition leaves both versions in scope, and the round then reports clauses from language nobody is bound by any more. Where Coverbase is unsure, the document is marked **Check this**.
Then open **Upload vendor response** and confirm what this round reads. Everything on the contract is read unless you unpick it.
<Frame>
<img alt="Dialog listing the contract's documents with checkboxes, a link to add the returned document, and a compare against round 1 button" />
</Frame>
Press **Compare against round 1**.
<Note>
The round inherits the clause sets and reviewer of the round it answers. The reply is measured against what the vendor was asked for; swapping the standard mid-way would grade them on something they never saw.
</Note>
## Step 2: See what changed
The round opens on its answer, before you review a single clause.
<Frame>
<img alt="Round summary reading the vendor answered 6 of your 9 asks, with buckets for unasked edit, countered, not addressed, accepted and unchanged" />
</Frame>
| Bucket | What it means | What to do |
| - | - | - |
| **Unasked edit** | The vendor edited a clause you never raised, including ones you accepted in an earlier round. | Read every one. This is the bucket that catches quiet edits. |
| **Countered** | They moved, but the language still falls short of the tier you asked for. | Decide whether the counter is good enough. |
| **Not addressed** | You asked; nothing changed. | Decide whether to press again, accept the risk, or drop it. |
| **No longer present** | A clause the previous round read is not in the returned document. | Check whether it was removed deliberately. |
| **Newly present** | A clause you check for appears for the first time. | Read it; nothing about it was decided before. |
| **New standard** | You added this clause to your standard since the previous round. | Review it as you would in a first round. |
| **Accepted** | The language now meets the tier you asked for. | Nothing, unless you disagree with the read. |
| **Unchanged** | Untouched, so your earlier decision stands. | Nothing, unless no round ever decided it, in which case it stays in the queue. |
**Unasked edits are listed first.** An edit in a clause you already signed off is the change a returned document is most likely to hide.
**Review what needs you** opens the queue with the riskiest bucket first; **Show all** walks every clause the round read.
## Step 3: Review what needs you
The queue holds what this round needs a decision on: the clauses the vendor edited, the asks they left unanswered, and anything no round has decided yet. Every row says what happened to it.
<Frame>
<img alt="Clause row showing an unasked edit badge beside a non-conforming status badge" />
</Frame>
<Frame>
<img alt="Clause row showing an unchanged badge beside a conforming status badge" />
</Frame>
Use **Show all** if you would rather walk every clause, the same way you can in round 1.
## Step 4: Decide on a counter
When you open a clause the vendor countered, the middle pane compares **what you asked for** against **what came back**, rather than making you re-read the whole clause. The changed language is highlighted, and Coverbase says in one sentence why it counts the reply as a counter rather than an acceptance.
<Frame>
<img alt="Clause comparison showing the previous round's language struck through and the vendor's returned language highlighted, above the suggested redline and an explanation of why it is a counter" />
</Frame>
Read the top block as a report and the block below it as a proposal. The top one says what the vendor did; the **Suggested redline** underneath still argues for your standard, so its struck words are the contract's and its highlighted words are yours.
A clause the vendor left alone shows the decision you already made rather than asking again:
<Frame>
<img alt="Clause showing an unchanged badge and a line reading your round 1 decision stands, non-conforming" />
</Frame>
An ask the vendor ignored is still queued, though nothing moved, because you still have to decide what to do about it:
<Frame>
<img alt="Clause showing a not addressed badge and the explanation that the language is unchanged" />
</Frame>
Your four verdicts are unchanged from round 1: accept as-is, flag for the vendor, accept the risk, or not applicable. **Save** records the verdict; **Skip for now** moves on without recording one.
## Step 5: Send the next round
The follow-up drafted at the end of a round carries only what is still open.
* An ask the vendor **accepted** is settled and never re-raised.
* An ask they **countered** comes back as a fresh ask about their language, not a repeat of yours.
* An ask they **did not address** is restated.
* A clause they **changed without being asked** becomes a new ask, if you flagged it.
The follow-up never re-sends an ask the vendor already agreed to.
<Note>
Coverbase proposes which of your asks were accepted; it does not settle them quietly. When the reading is not clear-cut, the ask is left for you to confirm on the round summary, because marking an ask accepted removes it from every future message.
</Note>
<Frame>
<img alt="Round summary with a confirm what the vendor agreed to panel listing two asks, each with they accepted it and they countered buttons" />
</Frame>
A round where the vendor accepted everything says so rather than opening an empty queue:
<Frame>
<img alt="Round summary with only accepted and unchanged buckets and a line reading nothing in this round needs a decision" />
</Frame>
## What to check on every round
<Steps>
<Step title="Read the unasked changes first">
Every clause in that bucket, even the ones you accepted last time.
</Step>
<Step title="Confirm the new-version-versus-new-document call on the Documents tab">
One wrong call there makes the whole round report on superseded language.
</Step>
<Step title="Confirm the proposed acceptances">
Anything Coverbase was unsure about is waiting for your tick on the summary.
</Step>
<Step title="Look at what was not addressed">
Decide whether to press it again or let it go, rather than sending the same sentence a third time.
</Step>
</Steps>
## Related guides
<CardGroup>
<Card title="Contract Guardian" icon="file-contract" href="/user-guides/contract-guardian">
Build a clause set, run the first review, decide each flagged clause, and send the redline.
</Card>
<Card title="Contract components" icon="puzzle-piece" href="/user-guides/contract-components">
How Coverbase decides which document carries which part of an agreement, and what happens when a new document supersedes an old one.
</Card>
</CardGroup>
# The contract Spend tab
Source: https://docs.coverbase.com/user-guides/contract-spend
What a contract costs: the priced lines read from its documents or added by hand, how the annual total is worked out, how currencies are handled, spend across renewals, and other contracts in the same spend category.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Spend** tab on a contract record. For the rest of the record, including the **Terms** card where the contract value is edited, see the [Contracts workspace guide](/user-guides/contracts-workspace). For how Coverbase decides which document's money counts toward the contract value, see [Contract components](/user-guides/contract-components). For bringing in a folder of contracts you already hold, see [Contract Assembly](/user-guides/contract-assembly).
</Info>
The **Spend** tab answers two questions about one contract: what it costs, and how that has changed. It lists every charge the contract's documents state, adds up what is still in force, draws spend across the contracts this one renews, and names other contracts your organization holds for the same kind of purchase.
The mistake people make most often is reading **Annual spend from priced lines** and **Contract value (from Terms)** as two versions of one number. The first is a yearly figure added up from the lines on this tab. The second is the value recorded for the whole contract on the **Terms** card. Coverbase shows them side by side and never reconciles, compares, or converts one into the other.
## Where to find it
Open a contract and choose the **Spend** tab, between **Workflow** and **Activity**. The **Related** card on the contract's **Overview** links to it too, with **Spend tab**.
<Note>
**Spend over time**, **Also buying**, and the **Related** card are part of a newer contracts experience. If you do not see them, ask your Coverbase account team to turn it on. The priced lines and the figures above them are there either way.
</Note>
## The figures at the top
<Frame>
<img alt="Spend tab showing annual spend from priced lines, contract value from Terms, the also buying card, and a list of priced lines with a superseded section" />
</Frame>
| Card | What it shows | Where the number comes from |
| - | - | - |
| **Annual spend from priced lines** | The yearly cost of every line still in force. Underneath: how many lines that is, how many were added by hand and how many documents the rest come from, and any **one-off charges**. | The priced lines on this tab. |
| **Contract value (from Terms)** | The value recorded for the whole contract. When it was entered as a yearly breakdown, the card shows the sum of the years. | The **Terms** card on the **Overview**. **Add in Terms** or **Edit in Terms** takes you there. |
| **Also buying** | The contract's spend category, how many other contracts share it, and their combined value. **see them** jumps to the list further down the tab. When no other contract shares the category, the card names the category and reads **No other contracts in this category**. | See [Also buying](#also-buying). |
A dash in the first card means there is nothing to total: the contract has no lines in force, or its lines are in more than one currency. With no lines at all, the card reads **No priced lines yet**.
## Priced lines
A priced line is one charge: a subscription fee, a support fee, an hourly rate, a discount. Each line has a description, an amount, a currency, and a frequency.
### Where lines come from
* **Read from the documents.** When a document is added to the contract, Coverbase reads the contract's documents for the charges they state and notes the page each figure is on. **Read prices from documents**, above the list, asks for that reading again. It also re-reads the contract's [components](/user-guides/contract-components). The button appears only when the contract has at least one document.
* **Added by hand.** **Add a line** records a charge the documents do not state, or one the reading missed.
Those are the only two sources. There is no feed from invoices, purchase orders or payment systems: the tab shows what the contract says, not what was paid. Contracts created by [Contract Assembly](/user-guides/contract-assembly) or by bulk creation are read the same way once their documents arrive.
What the reading counts, and what it leaves out:
* It skips liability caps, insurance limits, not-to-exceed ceilings, and penalties. They limit what may be owed; they are not charges.
* It keeps discounts and credits as negative lines, so they reduce the total.
* It drops any figure over one billion, which is a limit rather than a price.
* It skips documents filed on the contract as a quote, a redline draft or a duplicate, and an amendment already incorporated into a conformed copy. Reading them would count an offer nobody accepted, or the same charge twice. A quote or draft filed as the agreement itself is still read, so remove its lines by hand.
* Each line read from a document takes the effective date filed for that document, when it has one.
* A price stated with a bare `$` is read as US dollars unless the document names another currency. If the contract is priced in Canadian, Australian or another dollar, check the currency on each line.
**Reading prices again replaces the previous reading.** Every line read from the documents is replaced by the new one. Lines you added or corrected by hand stay as they are, and a line you removed is not read back in from the document it came from. The same charge read from a different document still appears.
The reading runs in the background and usually takes a minute or two. A message confirms it has started, and the tab refreshes on its own for the next two minutes. A long contract can take longer, so reload the tab if nothing has changed.
### Reading the list
The list has four columns: **Line**, **Frequency**, **Amount**, and **Yearly**. Lines are grouped under the document that states them, the largest yearly contributor first, and each group header shows what that document adds a year. Click a document's name to open it on the **Documents** tab. Lines added by hand sit together under **Not from a document**.
Under each description you may see **Page 4**, the page the figure was read from, **Effective** and the date the line took effect, or **Added by hand** on a line a person added or corrected.
The **Yearly** column turns each line into a cost per year:
| Frequency | Yearly |
| - | - |
| **Annual** | The amount. |
| **Quarterly** | The amount times 4. |
| **Monthly** | The amount times 12. |
| **One-off** | A dash. The charge happens once, so it is shown as **one-off charges** in the top card instead. |
| **Metered** | **Metered**. A usage rate has no committed amount, so there is nothing to multiply. |
### How the annual total is worked out
**Annual spend from priced lines** is the sum of the **Yearly** column for every line in force. One-off and metered lines add nothing to it, negative lines reduce it, and lines under **Superseded** do not count. Nothing is estimated and nothing is converted.
### Lines that replace each other
A charge is often priced more than once: an order form sets a subscription, and an amendment re-prices it at a new tier. Coverbase counts such a charge once. Lines that name the same charge, with tier and size words set aside ("Tier 2", "(250 seats)"), are treated as one charge restated. One of them counts. The others move to **Superseded** at the foot of the list, struck through and marked **Replaced by a later line**. Click **Show** to open the section.
Which line counts is decided in this order:
1. The line with the latest effective date. A line with no date counts as older than any dated line.
2. At the same date, or with no dates, a line added or corrected by hand, ahead of a line read from a document.
3. After that, the line added most recently. For lines read from documents, that is the line from the document added to Coverbase last.
<Frame>
<img alt="Priced lines with the superseded section expanded, showing a struck-through line marked replaced by a later line" />
</Frame>
The document added last is not always the later agreement, for example when an old contract is uploaded after its renewal. When the order matters, give the current line an **Effective date**.
Lines that describe one charge in different words ("Platform fee" and "Annual subscription") both count, because nothing ties them together. Remove the one that is no longer in force.
### Adding, correcting and removing a line
<Frame>
<img alt="Add a line dialog with fields for what is being charged, amount, currency, frequency and effective date" />
</Frame>
<Steps>
<Step title="Open the form">
Click **Add a line**. To fix an existing line, hover it and click the pencil, **Correct this line**.
</Step>
<Step title="Describe the charge">
**What is being charged** names it. **Amount** accepts a negative figure for a discount or credit. **Currency** is picked from the list of currency codes, such as `USD`, `EUR` or `GBP`, and starts at `USD`. **Frequency** is **One-off**, **Monthly**, **Quarterly**, **Annual**, or **Metered**. **Effective date** is optional: when two lines price the same charge, the one with the later date counts. **Clear date** removes it.
</Step>
<Step title="Save">
Click **Save line**. The line is marked **Added by hand**, and reading the documents again will not overwrite it.
</Step>
</Steps>
To take a line out of the total, hover it and click the bin, **Remove this line**. There is no confirmation and no undo. To bring a removed line back, add it again by hand.
Correcting a line's amount, currency, frequency or date never changes which charge it is matched to, and neither does rewording a line the reading named. Rewording a line you typed yourself matches it on the new description, so it can join or leave another line; check the total and the **Superseded** section afterwards.
Adding, correcting, and removing lines needs permission to edit the contract.
## How currencies are handled
Coverbase does not convert currencies anywhere on this tab. Every figure stays in the currency it was stated in, and a total appears only when everything it would add up is in one currency.
| Where | Everything in one currency | More than one currency |
| - | - | - |
| **Annual spend from priced lines**, **one-off charges**, and each document's yearly figure | Totalled in that currency. | Not totalled. The card shows a dash, and the list says **Lines are stated in more than one currency, so they are not totalled.** |
| Each priced line | Shown in its own currency. | Shown in its own currency. |
| **Contract value (from Terms)** | Shown in the currency recorded on the **Terms** card. | Not applicable. A contract value has one currency. |
| **Spend over time** | Bars in that currency, with a growth rate and a forecast. | Each bar in its own currency, drawn to scale only against bars in the same currency, with a note under the chart. No growth rate or forecast. |
| **Also buying** | A combined value for every other contract in the category. | No combined value. The header reads **totals span currencies**. |
Only lines in force decide whether a total is shown. A superseded line in another currency does not stop it.
<Frame>
<img alt="Spend tab with a dash for annual spend and a note that lines are stated in more than one currency" />
</Frame>
If a line carries the wrong currency, correct it and the total comes back. If the contract really charges in two currencies, the total stays blank; read the lines instead.
<Warning>
**Coverbase never compares the first two cards.** A contract priced in euros on its lines and recorded in dollars on the **Terms** card shows both figures as they are, with nothing to say they differ. Check the currency on the **Terms** card when you record a value.
</Warning>
## Spend over time
<Frame>
<img alt="Spend over time card with four yearly bars, a pale forecast bar, a growth rate compared with inflation, and a link the previous contract button" />
</Frame>
The **Spend over time** card draws one bar per year: the contracts this one renews, then this contract, then any contract that renews it. The amounts come from each contract's **Terms** card, not from the priced lines.
How each contract becomes bars:
* **With a yearly breakdown** on its **Terms** card, one bar per year, as entered.
* **With a single value over a term longer than a year**, the value split evenly across the years. That is an even split, not a claim about the schedule, so enter a yearly breakdown where the price steps up.
* **With no value**, one bar marked **Not recorded**.
Each bar is labeled with the calendar year it starts in, or **Year 1**, **Year 2** and so on when the contract has no start date. Hover a bar to see which contract it came from.
A contract with no linked previous contract still gets a chart when it has a yearly breakdown. With a single value and no link, the card shows only **Link the previous contract**.
### Linking the contract this one renews
Coverbase does not guess which contract a renewal replaces. You link them.
<Steps>
<Step title="Open the picker">
Click **Link the previous contract** at the bottom of the card. The same control sits under **Renews** on the **Related** card.
</Step>
<Step title="Pick the contract">
Search this vendor's contracts and pick the one this contract replaces. Only the same vendor's contracts are offered.
</Step>
<Step title="Check the chart">
The card now reads **Renews** and the previous contract's name, and that contract's years join the chart. Click the name to open it.
</Step>
</Steps>
**Change** picks a different contract, and the unlink icon beside it removes the link. Each contract can be renewed by one contract only, and a link that would loop back on itself is refused. An archived contract stays in a chain it already belongs to, so a superseded agreement still supplies its years. Linking needs permission to edit the contract.
When [Contract Assembly](/user-guides/contract-assembly) imports an agreement that starts where an existing contract with the same vendor ends, it proposes the link, and confirming the new contract makes it.
### Growth and the forecast year
With two or more priced years in one currency, the card header shows the compound yearly growth across them, for example **3-year CAGR +5%**, beside the latest 12-month change in the US consumer price index for comparison.
The last bar, drawn pale, forecasts the year after the last priced year. The note under the chart says where its rate came from. Coverbase uses the first of these that exists:
| Basis | The note ends with | When |
| - | - | - |
| The contract's escalator | "this contract's own 4% escalator" | A contract in the chain commits to a yearly percentage increase. The latest such rate is used. Coverbase reads it from the documents; it cannot be edited on the page. |
| Observed growth | "the 5% the chain has grown at" | No escalator, and at least two priced years. |
| Inflation | the index and its rate, "not from anything the contract says" | Neither of the above. The weakest basis. |
The growth rate is spread over the years that passed between the first and the last priced year, not over the number of bars. A chain with a gap, such as a year between two contracts that nothing covered, is not made to look steeper.
<Note>
If the yearly breakdown was filled in with **Estimate with CPI average** on the **Terms** card, the growth and the forecast repeat that estimate rather than anything the contract says.
</Note>
## Also buying
When Coverbase summarizes a contract, it assigns a spend category from a fixed list, such as **Cloud & infrastructure** or **Identity & access**. The category is the first tag on the **Summary** card. The **Also buying** card lists the other contracts in the same category, so you can see whether you pay several vendors for the same thing.
* It lists the other contracts that are not archived, canceled or expired, the most valuable first. Each shows its vendor, **Renews** and a date (or **Auto-renews**), and its contract value, or **Not recorded**.
* The first ten are shown. With more, the foot of the card reads, for example, **4 more contracts in this category**; click it to open the rest on the card. The card lists up to 50, and says how many more there are beyond that.
* The header gives how many contracts share the category and their combined value, across every one of them, not only those shown.
* The combined value is withheld when the contracts use different currencies, and the header reads **totals span currencies**. It is also withheld when any of them has no value recorded, and the header says how many have none.
* The card does not appear when the contract has no category, or when no other contract shares it. The top card reads **No spend category yet** in the first case. In the second, it names the category and reads **No other contracts in this category**.
There is no control for changing a contract's category on the page. If a category is wrong, ask your Coverbase account team.
The priced lines are only on this tab. The contracts list and the [dashboards](/user-guides/dashboard-library) report the contract value from the **Terms** card.
## Troubleshooting
| Symptom | Cause | Fix |
| - | - | - |
| **Annual spend from priced lines** shows a dash. | No lines are in force, or the lines in force use more than one currency. | Add or read lines. If a line has the wrong currency code, correct it. |
| One charge is counted twice. | Two lines describe it in words different enough to count as two charges, or a quote or duplicate document was read. | Remove the line that is no longer in force. |
| The old price counts and the new one is under **Superseded**. | Both lines describe the same charge, and the old one has the later effective date, or neither has a date and the old one was added later. | Give the current line an **Effective date**, or remove the old line. |
| Nothing appeared after **Read prices from documents**. | The reading is still running, or the documents state no charge it recognized. | Reload the tab after a few minutes. Add missing charges by hand. |
| **Read prices from documents** is missing. | The contract has no documents. | Attach one on the **Documents** tab, or add lines by hand. |
| The lines changed after someone uploaded a document. | Adding a document reads the prices again and replaces every line read from the documents. | Check the total and **Superseded**. Lines added or corrected by hand were kept. |
| A line I removed came back. | It was read again under a different description, or from another document on the contract. | Remove it again, or correct it if the figure is right but described differently. |
| **Spend over time** shows only **Link the previous contract**. | The contract has no yearly breakdown and no linked contract with values. | Add a yearly breakdown on the **Terms** card, or link the previous contract. |
| "Could not link that contract". | The contract you picked is already renewed by another contract, or the link would loop. | Unlink it from the contract that renews it, or pick a different one. |
| **Spend over time** shows bars in two currencies and no growth rate. | The contracts in the chain use different currencies, and nothing is converted. | Read each bar in its own currency; hover it to see which contract it is. |
| **Also buying** says some contracts have no value recorded. | Those contracts have no value on their **Terms** card, so any combined figure would be too low. | Record the value on each contract's **Terms** card. |
## Related
<CardGroup>
<Card title="Contracts workspace" icon="folder-open" href="/user-guides/contracts-workspace">
The contract record: the **Terms** card where the contract value and yearly breakdown are edited, and the other tabs.
</Card>
<Card title="Contract components" icon="puzzle-piece" href="/user-guides/contract-components">
Which document's money counts toward the contract value, and why a quote or a liability cap never does.
</Card>
<Card title="Contract Assembly" icon="layer-group" href="/user-guides/contract-assembly">
Import a folder of existing contracts, including the renewal links between them.
</Card>
<Card title="Dashboards and the chart library" icon="chart-line" href="/user-guides/dashboard-library">
The Contract Spend & Renewals dashboard: committed spend across the portfolio.
</Card>
</CardGroup>
# The contracts repository
Source: https://docs.coverbase.com/user-guides/contracts-repository
Forward an agreement to your organization's paralegal inbox, understand how Coverbase names, deduplicates, versions and files it, check what the AI read off it, and manage the folders and settings behind the inbox.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Contracts → Repository**: the inbox, the folder browser, the document page and the settings behind them. For the contract records you track renewals and clauses on, see the [Contracts workspace guide](/user-guides/contracts-workspace). For raising a new contract and getting it signed, see [Contract intake and approval](/user-guides/contract-intake-and-approval).
</Info>
<Note>
The Contracts Repository is an optional module. If you do not see **Repository** under **Contracts** in the left navigation, ask your Coverbase representative to turn it on. Mail sent to your organization's inbox address before the module is switched on is kept, and appears once it is.
</Note>
The repository is a filing inbox. Your organization gets an email address. Forward, CC or BCC any email with agreements attached to it, and each attachment is read, given a title, checked against what you already hold, and filed into a folder. You can also upload files from the page itself. The result is one row per agreement, with every version and everything that happened to it in one place.
It does only the sorting. Nothing in the repository reviews a clause, chases a signature, or sets a renewal reminder. Those belong to the contract records in the [contracts list](/user-guides/contracts-workspace), and a filed document does not become a contract record on its own. To turn a back catalog into contract records, use [Contract Assembly](/user-guides/contract-assembly).
The mistake people make most often is forwarding from an address the inbox does not trust. Only mail from your organization's own domains, its members, or domains you have added is filed. Anything else is logged as **Sender not allowed** and its attachments are dropped. If you forwarded something and nothing appeared, the [inbox log](#the-inbox-log) is the first place to look.
## Where it lives
Open **Contracts** in the left navigation and choose **Repository**. The page has four screens:
| Screen | How to reach it | What it is for |
| - | - | - |
| **Repository** | The nav item | Your inbox address, the folder tree, and the documents in the selected view |
| A document page | Click a row | One agreement: its details, versions and history |
| **Inbox log** | Button at the top right of the repository page | Every email that reached the inbox and what became of it |
| **Settings** | Button at the top right of the repository page | The address, who may send to it, the filing scheme and starting folder structures |
<Frame>
<img alt="The repository page showing the paralegal inbox address, four stat tiles, a folder tree and a table of filed documents" />
</Frame>
## Forwarding an agreement
<Steps>
<Step title="Copy the address">
It is at the top of the repository page under **Your paralegal inbox**, with a copy button next to it. The address ends in `@paralegal.coverbase.app`. It is also shown on the **Settings** page.
</Step>
<Step title="Forward, CC or BCC the email">
Any of the three works. Attach the agreement, or forward the email it arrived on. You can add anything after a plus sign (`acme+legal@...`) and it still reaches the same inbox, which is useful for mail rules.
</Step>
<Step title="Wait for filing">
The message appears in the inbox log at once. The attachments are filed a short while later, and the **Emails received** and **Documents** tiles on the repository page update.
</Step>
</Steps>
### Who can forward
The address is easy to guess, so the inbox checks the sender before it stores anything.
| Sender | What happens |
| - | - |
| An address on one of your organization's email domains | Filed |
| An active member of your workspace | Filed |
| An address on a domain listed under **Additional allowed domains** in Settings | Filed, and every document is marked **Needs review** |
| Anyone, when **Accept mail from anyone** is on | Filed, and every document is marked **Needs review** |
| Anyone else | Logged as **Sender not allowed**. No attachments are stored. |
The organization's own domains and **Workspace members** are always allowed. The other two rows are settings you turn on; see [Settings](#settings).
### What happens to the attachments
Only files that can be an agreement are kept: `.pdf`, `.docx`, `.doc`, `.txt`, `.md` and `.rtf`. Images, calendar invites, spreadsheets and inline pictures such as signature logos are dropped before anything is stored. The first few thousand characters of the email body are kept as context for the classifier, never the whole thread.
An attachment that is a readable file but not an agreement, such as an invoice or a receipt, is read and then dropped. It does not appear in any folder. The inbox log still shows the message, with an **Outcome** of `0 filed`.
<Tip>
A `.msg` or `.eml` file attached to a forwarded email is not filed. If you want the agreement inside it, forward the original email instead of the saved copy.
</Tip>
### Uploading from the app
Click **Upload documents** at the top right of the repository page and pick one or more `.pdf`, `.docx`, `.doc`, `.txt` or `.md` files. Uploads go down the same path as a forwarded email: classified, checked for duplicates, versioned and filed by the scheme. You do not choose the folder at upload time. If the scheme puts a file in the wrong place, move it afterwards.
Uploads show in the inbox log with your name as the sender and the subject **Uploaded in the app**.
## How a document is filed
Each attachment goes through the same four checks, in this order.
<Steps>
<Step title="Duplicate check">
The file's contents are fingerprinted. If any live document already holds that exact file in any of its versions, nothing new is created. The existing document gets a **Duplicate ignored** entry in its history and the message counts it under `duplicates`.
</Step>
<Step title="Classification">
The AI reads the first pages of the document (up to twelve pages) together with the email's sender, subject and body excerpt, and returns: whether the file is an agreement at all, its type, a short title a paralegal would use, the counterparty, every named party, the effective and expiry dates as written in the paper, a summary, a one-sentence reason, and a confidence figure. The email is context only. A subject line saying "signed NDA" does not override what the document says.
</Step>
<Step title="Version or new document">
The arrival is compared with live documents of the same type and counterparty. If the titles agree once version markers are stripped (`v3`, `final`, `executed`, dates, `(2)`), or the file names do, it becomes a new version of that document. Otherwise it is a new document. When in doubt the repository creates a new document, because two rows are easy to spot and merge by hand, and a version buried inside the wrong document is not.
</Step>
<Step title="Filing">
A new document is placed by the folder scheme in Settings. Folders that do not exist yet are created. The document's history records **Received** and **Filed into** the folder.
</Step>
</Steps>
A document is marked **Needs review** instead of **Filed** when the classifier's confidence is below the threshold in Settings (60% by default), or when the sender was a guest (an allowed domain or anyone, rather than a member). A scanned PDF with no text layer is classified from its file name alone, which lands it in review.
## Reading the repository page
Four tiles sit under the address:
| Tile | What it counts |
| - | - |
| **Documents** | Every live document, across all folders and unfiled |
| **Needs review** | Documents waiting for a person to confirm the classification |
| **Folders** | Live folders in the tree |
| **Emails received** | Every message that reached the inbox, with a `failed` count when any did not finish |
The left column is the folder tree. Three views sit above the folders:
* **All documents**: everything, regardless of folder.
* **Needs review**: only documents marked for review. Work this list down to zero.
* **Unfiled**: documents with no folder. A document lands here when you delete its folder from the top level, or move it to **Unfiled** on purpose.
Click a folder to see its documents and those of its subfolders. The path appears above the table, and each segment is clickable.
The table has these columns:
| Column | What it shows |
| - | - |
| **Title** | The AI's title, or the one you gave it. Click to open the document |
| **Type** | The document type, as a badge |
| **Counterparty** | The other party |
| **Status** | **Filed** or **Needs review** |
| **Version** | `v1`, `v2`, and so on: how many versions the row holds |
| **Effective** | The effective date, when the paper states one |
| **Received** | When the latest version arrived. The default sort, newest first |
Above the table: **Search documents**, a **Document type** filter, and **Filter by sender email**. The sender filter matches any address a version arrived from.
The menu at the end of each row offers **Download** (a link that expires after 15 minutes), **Move to folder** and **Archive**.
## Folders
The plus button next to the **Folders** heading is **New folder**. The menu on any folder offers **New subfolder**, **Rename folder** and **Delete folder**. A folder has a name and an optional description; the description is shown next to the name so colleagues file the same way.
**Delete folder** archives the folder and everything beneath it. Its documents move up one level, to the parent folder or to **Unfiled**. Nothing leaves the repository.
The scheme decides the folders an incoming document is filed into. Every scheme starts with a folder per category, so switching schemes later only changes what sits beneath those.
| Scheme | Example path |
| - | - |
| **One folder per category** | `Vendors / MSA with Acme Corp.pdf` |
| **A folder per counterparty** (default) | `Vendors / Acme Corp / MSA with Acme Corp.pdf` |
| **A folder per counterparty, then per document type** | `Vendors / Acme Corp / Statement of work / SOW 2.pdf` |
Renaming a category folder does not break filing. The repository finds it by its role, not its name, so `Vendors` renamed to `Suppliers` keeps receiving vendor paper.
The category comes from the document type:
| Category | Document types |
| - | - |
| **Customers** | Customer agreement, Terms of service |
| **Vendors** | Master services agreement, Statement of work, Order form, Vendor agreement, License, Data processing agreement |
| **Partners & NDAs** | NDA, Partnership agreement |
| **People** | Employment agreement, Offer letter, Contractor agreement, Advisor agreement |
| **Corporate** | Equity, Corporate |
| **Finance & Insurance** | Loan, Insurance |
| **Real estate** | Lease |
| **Other** | Amendment, Other |
## The document page
Click a row to open it.
<Frame>
<img alt="A repository document page with type and status badges, a Filed in card, a Details form, a Sources card, a Versions list and a History timeline" />
</Frame>
The header shows the title, the type and status badges, the current version number, the file name and its size. The buttons on the right are **Download**, **Mark reviewed** (only while the status is **Needs review**), **Move to folder**, and **Archive** or **Restore**.
| Card | What it holds |
| - | - |
| **Filed in** | The folder path. Each segment opens that folder in the browser. **Unfiled** if the document has no folder |
| **Details** | **Title**, **Type**, **Category**, **Counterparty**, **Effective**, **Expires** and **Summary**, all editable. Below them, the named **Parties** and a line reading `Classified with N% confidence: <reason>` |
| **Sources** | **Sent by**: every address a version arrived from, each a link that filters the browser to that sender. **Sent to**: the inbox addresses it reached |
| **Versions** | Newest first. Each shows its file name, when it arrived, who sent it, and any version marker found in the file (`final`, `v3`). The download icon fetches that version |
| **History** | Every event on the document, newest first, with who did it and when |
Events you will see in the history:
| Event | Meaning |
| - | - |
| **Received** | The first version arrived, with the file name and sender |
| **Filed** | Placed into a folder by the scheme |
| **New version** | A later version was added, with its number and file name |
| **Duplicate ignored** | The same file arrived again and was not stored twice |
| **Moved** | A person moved it to another folder |
| **Renamed** | A person changed the title, shown as `old → new` |
| **Reclassified** | A person changed the type, category or counterparty |
| **Archived** / **Restored** | A person archived it, or brought it back |
### Correcting what the AI read
Every field the classifier filled in can be changed. Edit the fields in **Details** and click **Save**. Changing the title writes a **Renamed** event; changing the type, category or counterparty writes **Reclassified**. Changing the category does not move the document; use **Move to folder** for that.
To clear a **Needs review** flag, check the details, fix what is wrong, then click **Mark reviewed**. The status changes to **Filed** and the document leaves the **Needs review** view.
<Warning>
Archived documents leave every list and every view, including search. The **Restore** button is on the document page, so keep the link if you may need it back. Nothing is deleted: the versions and the history stay.
</Warning>
### Getting a filed document onto a contract record
The repository does not link a filed document to a vendor or to a contract record, and it does not create either. To track renewals or run a clause review on an agreement you filed, download it and attach it to the contract from the contract's **Documents** section, or raise a new contract from the vendor's **Contracts** tab as described in [Contract intake and approval](/user-guides/contract-intake-and-approval#raising-a-request).
## The inbox log
Click **Inbox log** at the top right of the repository page.
<Frame>
<img alt="The inbox log table listing received emails with sender, subject, attachment count, outcome and status columns" />
</Frame>
| Column | What it shows |
| - | - |
| **Received** | When the message arrived |
| **From** | The sender's name and address (or the uploader, for app uploads) |
| **Subject** | The email subject, or `(no subject)` |
| **Attachments** | How many files were stored from it |
| **Outcome** | `N filed · N versions · N duplicates` |
| **Status** | One of the statuses below, with the error text under it when there is one |
| Status | Meaning |
| - | - |
| **Received** | Stored and waiting for the filing run |
| **Filing** | The filing run is in progress |
| **Filed** | At least one document, version or duplicate resulted |
| **No documents** | The run finished and nothing was an agreement, or there were no usable attachments |
| **Sender not allowed** | The sender failed the check in [Who can forward](#who-can-forward). Nothing was stored |
| **Failed** | The run hit an error. The error is shown under the badge |
**Retry** appears on any row with stored attachments that is not currently filing. Retrying is safe: an attachment that was already filed is recognized by its fingerprint and skipped. A **Sender not allowed** row has no attachments to retry. Add the sender's domain in Settings and ask them to send again.
## Settings
Click **Settings** at the top right of the repository page. Change what you need and click **Save** at the top.
<Frame>
<img alt="The Repository Settings page with the Inbox Address, Who Can Send, Filing and Starting Structures sections" />
</Frame>
<AccordionGroup>
<Accordion title="Inbox Address" icon="at">
The part before the `@`. Letters, digits and hyphens, up to 40 characters, and unique across every Coverbase workspace, so a common word may already be taken. Changing it takes effect immediately and the old address stops working. Tell anyone who has a mail rule pointing at it.
</Accordion>
<Accordion title="Who Can Send" icon="user-check">
**Always allowed** lists your organization's email domains and **Workspace members**. **Additional allowed domains** is for outside counsel or a parent company: their documents are filed but flagged **Needs review**. **Accept mail from anyone** files every message and flags every document. Leave it off unless you have a reason; anyone who learns the address can then put documents in your repository.
</Accordion>
<Accordion title="Filing" icon="folder-tree">
**Folder scheme** is one of the three in [Folders](#folders); an example path updates as you change it. **Review below (% confidence)** sets the threshold under which a document is flagged for a person to check. The default is 60. Raise it to see more in **Needs review**, lower it to see less.
</Accordion>
<Accordion title="Starting Structures" icon="sitemap">
Three folder structures you can apply once with **Apply**: **Simple** (four folders), **Startup** (categories with subfolders for employees, contractors, advisors, formation, financing, equity, banking, insurance) and **Detailed** (agreements separated by type inside each category). Applying one creates the folders you do not have yet and leaves existing folders and their documents alone. You can rename, nest and delete the folders freely afterwards.
</Accordion>
</AccordionGroup>
## Permissions and notifications
Access follows the contract permissions. Anyone who can read contracts can open the repository, browse, search and download. Anyone who can update contracts can also upload, move, rename, reclassify, archive, restore and mark reviewed, manage folders, retry a message, and change Settings. Without update permission, the edit buttons and the **Details** fields are read-only. See [Permissions and roles](/user-guides/permissions-and-roles) for how those permissions are granted.
The repository sends no emails. It does not confirm receipt to the sender and does not notify anyone when a document lands in **Needs review**. Check the **Needs review** tile.
## Emails as evidence
A related job lives outside the repository. When a vendor replies on an email thread and you want that thread on file as evidence, save the email as a `.msg` or `.eml` file and upload it to the vendor's documents like any other file. Coverbase renders the headers and body to a PDF, so the sender's words are previewable, searchable and quotable in an assessment, and every real attachment becomes a document of its own, listed under **Attachments extracted from** the email. Signature images and logos are not kept. An attachment the email only referenced rather than carried is named on the rendered page so the list is not silently short.
This is separate from the repository: the repository's inbox does not accept `.msg` or `.eml` attachments, and a vendor document does not appear in the repository.
## Troubleshooting
| What you see | What is happening |
| - | - |
| "I forwarded an email and nothing appeared." | Open **Inbox log**. If the row says **Sender not allowed**, you sent from an address the inbox does not trust; add the domain under **Additional allowed domains** or forward from your work address. If there is no row at all, check the address you used against the one on the repository page. |
| "The row says **No documents**." | Nothing attached was an agreement, or the attachments were types the inbox drops (images, spreadsheets, calendar invites, `.msg` files). Check the **Attachments** column: `0` means nothing usable was stored. |
| "The row says **Failed**." | The filing run hit an error, shown under the badge. Click **Retry**. Anything already filed is skipped. |
| "The same agreement is in two rows." | The titles or file names were too different for the versioning check to match them. Open the older one, note its folder, and archive whichever you do not want to keep. |
| "A new draft became a version of the wrong document." | Same type, same counterparty, and a title or file name that looked alike. A version cannot be detached, and forwarding the same file again is ignored as a duplicate while the document is live. Archive the document, forward or upload both files again so each is filed on its own, then correct the details on the new rows. |
| "Everything is landing in **Needs review**." | Either the threshold in Settings is high, or the mail is coming from a guest domain. Guests are always flagged. Lower **Review below (% confidence)** if the classifications are right. |
| "A scanned PDF was filed as **Other** with low confidence." | There was no text to read, so the classifier used the file name. Fix the type and counterparty in **Details** and click **Mark reviewed**. |
| "I renamed the Vendors folder and new documents still go into it." | That is expected. The scheme files by the folder's role, not its name. |
| "I changed the address and colleagues' mail bounces." | The old address stopped working as soon as you saved. Send them the new one. |
| "Settings will not save: 'That address is taken.'" | The address is unique across every Coverbase workspace. Pick another. |
| "I archived a document and cannot find it." | Archived documents leave every list. Open it from the link you had and click **Restore**. Forwarding the file again does not restore it; an archived document is ignored by the duplicate check, so the file is filed as a new document. |
## Related
<CardGroup>
<Card title="Contracts workspace" icon="folder-open" href="/user-guides/contracts-workspace">
The contracts list and the contract record: where renewals, values and clauses are tracked.
</Card>
<Card title="Contract intake and approval" icon="clipboard-check" href="/user-guides/contract-intake-and-approval">
Raise a contract from a vendor, confirm what the AI read off the draft, and send it for signature.
</Card>
<Card title="Contract components" icon="puzzle-piece" href="/user-guides/contract-components">
What a contract record reads each attached document into.
</Card>
<Card title="Permissions and roles" icon="users" href="/user-guides/permissions-and-roles">
Who can read and update contracts, and how to grant it.
</Card>
</CardGroup>
# Contracts workspace
Source: https://docs.coverbase.com/user-guides/contracts-workspace
How to read the contracts list page and the contract record: the attention cards, the table and the renewal runway views, and the cards on a contract.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the screens you work in every day. For what Coverbase reads each document into, see the [Contract components guide](/user-guides/contract-components). For running clause reviews, see the [Contract Guardian guide](/user-guides/contract-guardian). For the dates behind reminders, see [Contract dates and reminders](/user-guides/contract-dates-and-reminders). For raising a new contract and getting it approved and signed, see [Contract intake and approval](/user-guides/contract-intake-and-approval). To turn a folder of contracts you already hold into records, see [Contract Assembly](/user-guides/contract-assembly).
</Info>
The contracts module has two screens: the list page, where you see the whole portfolio at once, and the contract record, where you work one agreement. This guide covers what each part shows and what you can change.
## The contracts list page
<Frame>
<img alt="Contracts list page with attention cards, toolbar, and contract table" />
</Frame>
Two sections stack down the page: the attention cards, then the list. The list has two views, a table and a renewal runway, and a toggle on the toolbar switches between them.
Beside the page title are three links: **Configuration** for lifecycle stages and reminders, **Guides** for this documentation, and **Reports** for the dashboards built on the portfolio.
### Attention cards
<Frame>
<img alt="Attention cards showing notice deadlines, renewal decisions needed, missing renewal details, and reviews needed" />
</Frame>
Four cards sit in one row. Each is a queue that needs someone to act, and the line under the figure says how urgent it is.
| Card | What it counts | The line beneath it |
| - | - | - |
| **Notice deadlines** | Contracts whose notice date is overdue or falls inside the next 90 days. | The window, and how many are already overdue. |
| **Renewal decisions needed** | Contracts inside that window with no renew or terminate decision recorded for this term. | How many are still ahead and fall due in the next 30 days. |
| **Missing renewal details** | Contracts set to auto-renew with no renewal term recorded. | How many of those terms end in the next 90 days. |
| **Reviews needed** | Contracts with a clause awaiting a decision, an assignment clause to re-read after a change of control, or a recorded value that disagrees with the document. | What the card covers. |
Click a card to filter the list below to exactly those contracts. Click it again to clear the filter. Each card is a saved view, so the filter it applies can be edited like any other, and the three review queues folded into **Reviews needed** are still available on their own from the view selector.
<Note>
**Reviews needed counts contracts, not problems.** A contract with an open clause and a value conflict is one review, because the list the card opens can only show it once.
</Note>
### The toolbar
Under the cards, one row holds the controls for the list: **Search**, the view selector (**All contracts** and your saved views), **Filter**, display options for the table's columns, the toggle between the **table** and the **renewal runway**, and **Preview**. On the right, **Actions** opens exports, notifications, uploads, bulk create, **Start a review** for a clause review, and, where your workspace has it, **Import contracts** and **View import batches** for [Contract Assembly](/user-guides/contract-assembly). **New contract** creates one.
The view toggle and **Preview** remember your choice in this browser. They do not change anything for your colleagues.
### The contract table
The table opens on the renewal story, left to right: **Contract**, **Vendor**, **Status**, **Notice due**, **Renewal decision**, **Renewal**, **Renewal term**, **Current term end**, **Relationship owner**, **Contract value**, and **Updated**. Columns marked **AI** hold values Coverbase extracted from the documents rather than values someone typed. The column picker offers the rest: **Term start**, **Effective date**, **Initial term**, **Termination notice**, **Contract length**, **Action date**, **Renewals applied**, **Contract type**, **Committed amount**, and every contract component.
A value nobody has recorded reads **Not recorded**. It turns orange where the gap is yours to close: a contract that renews automatically with no **Renewal term** will roll forward on a term nobody wrote down. A contract renewed by agreement has no renewal term, so that cell reads **Not applicable**.
Every row ends in a menu with the same four actions:
| Action | What it does |
| - | - |
| **Preview** | Turns on preview mode and shows this contract beside the list. |
| **View details** | Opens the contract record. |
| **Start clause review** | Starts a Contract Guardian review on this contract. |
| **Archive** | Hides the contract from the list after you confirm. |
### Previewing contracts
<Frame>
<img alt="Contract list with one row highlighted and a panel on the right showing the vendor, the contract name, its summary, and its renewal terms" />
</Frame>
Click **Preview** in the toolbar to look through contracts without leaving the list. A panel opens beside the table, or beside the runway, and shows the first contract. While preview mode is on:
* Click any row to show it in the panel. You do not need to close the panel first, and the rest of the page stays usable.
* The contract you are previewing stays highlighted in the list.
* Use the up and down arrows at the top of the panel, or the up and down arrow keys on your keyboard, to move to the previous or next contract. They follow the list as you have filtered and sorted it, and continue onto the next page. The panel shows where you are, for example **2 of 230**.
* Click **Open contract** at the bottom of the panel to open the full record.
The panel shows the vendor first. If the contract is an order form, SOW, or amendment under another agreement, that agreement comes next, and you can click it to open it. Then come the contract name, type, and status. Below that are the details that do not fit in a column: the summary or description, the term and renewal dates, the contract value and payment terms, owners, services, documents, and notes.
On a narrower screen, the panel opens over the right side of the list instead of beside it. The rows it does not cover still work the same way.
To leave preview mode, click **Preview** again or close the panel. With preview mode off, clicking a row opens the contract as usual. Holding Cmd or Ctrl while you click opens it in a new tab in either mode.
### The renewal runway
<Frame>
<img alt="Renewal runway with one lane per contract showing the notice deadline, the required notice span, and the current term end" />
</Frame>
Switch the toggle to the runway and the same rows are drawn as a calendar: one lane per contract, on a year of days from today. Filters, search, sorting, and paging carry over from the table.
Each lane carries three things, named in the legend:
| Mark | Meaning |
| - | - |
| Hollow circle | **Notice due**: the last day you can still give notice. |
| Line | **Required notice**: the span between the notice deadline and the term end. |
| Filled dot | **Current term end**: when the term ends. |
Today is the circled day at the left, with a line down every lane. Hover a mark to read its date, and click a row to open the contract. The row menu is the same one the table has.
A lane with no notice date says **Notice due date not recorded** where the mark would be, with a dotted line up to the term end. A notice date that has already passed sits on today as a filled mark, and its hover gives the date it fell on. A term end more than a year out runs off the right edge.
<Tip>
The notice deadline is the last day you can act, and it always comes before the term end. Read the lanes by their hollow circles first: that is the column of dates you are working to.
</Tip>
<Tip>
To find the contracts that cannot renew, click the **Missing renewal details** card, or filter on **Auto-renews** is **Automatic** and **Renewal Term** is empty. Those are the ones that will be marked expired instead of rolling forward.
</Tip>
## The contract record
<Frame>
<img alt="Contract record showing the header, the facts row, the tabs, and the Overview with its right rail" />
</Frame>
Open a contract from the table, the runway, or a search result. The top of the record says where the contract stands before you open a tab.
### The header and the facts row
The header carries the vendor's logo, the contract name, its type, and its status. Hover the logo for the vendor's website and risk analysts, and click it to open the vendor. Click the name to rename the contract, and click the status to move it to another stage.
On the right are **Copy link**, a button for the next step, and **Actions**, which holds **Configure lifecycle**, **Configure reminders**, and **Archive**. The next-step button names what the contract is waiting on: **Continue clause review** while a clause review has flagged clauses nobody has triaged, otherwise **Submit for approval**, **View approval**, **Send for signature**, or **Track signature**, following the [Workflow tab](/user-guides/contract-intake-and-approval).
Under the name, one row of facts: **Value**, **Term**, **Renewal**, **Notice Due**, **Owners**, and **Vendor Risk**. Nothing in the row is an editor. An empty fact links to the **Terms** card, where the value is edited, and **Owners** links to the **Team** card. A warning icon beside **Term** means the term dates disagree with the documents.
### The tabs
| Tab | What it holds |
| - | - |
| **Overview** | Where the contract stands and what needs someone, described below. |
| **Documents** | The files on the contract and what Coverbase read out of them. The tab shows how many files there are. |
| **Review** | Clause review, when Contract Guardian is on. The tab shows how many clauses the last review flagged. See the [Contract Guardian guide](/user-guides/contract-guardian). |
| **Workflow** | Reviews, metadata sign-off, the approval chain, and signature, as numbered steps. See [Contract intake and approval](/user-guides/contract-intake-and-approval). |
| **Spend** | The priced lines read from the documents, how spend has moved across renewals, and other contracts buying the same category. See [the contract Spend tab](/user-guides/contract-spend). |
| **Activity** | Everything that happened to the contract, with a switch to its **Notes**. |
Findings open from the **Findings** card on the Overview and take a tab of their own only while they are open.
### The Overview tab
The main column runs from what needs a decision to what the contract says:
1. **Reading documents**, only while Coverbase is still reading files on the contract
2. **Needs Attention**, described under [What needs attention](#what-needs-attention)
3. **Summary**, the AI read of the agreement
4. **Terms**, the one place the contract's own facts are edited
5. **Documents**, the files on the contract nested under what they amend, each marked with its role. **Upload** and **All documents and what they say** open the Documents tab.
The right rail holds **Team** (relationship owners and watchers), **Reviews**, and **Custom Fields**. **Vendor**, **Risks**, **Findings**, and **Related** (the contract this one renews, and other contracts buying the same category) join them when those parts of Coverbase are on for your organization.
### What needs attention
Everything on the contract that blocks a step or wants a decision sits in one list, with the action beside each line:
| Line | Action |
| - | - |
| The contract is held for intake review. | **Release for routing** |
| A recorded value disagrees with a document. | **Open the document**, **Fix in Terms** |
| The contract is set to auto-renew with no renewal term. | **Add renewal term** |
| A clause review has flagged clauses nobody has triaged. | **Continue review** |
| Components on the documents need attention. | **Review components** |
| Values approvers need are still empty. | **Add values** |
| A review is waiting on you. | **Record decision** |
The card is not shown when there is nothing to do.
### The terms card
<Frame>
<img alt="Terms card showing the date track, the term and renewal values, the renewal decision row, and the reminders row" />
</Frame>
Dates, term lengths, renewal, notice, cost, and the contract's description are edited here and nowhere else. A **Term 4** badge beside the title means the contract has renewed three times.
* **The track** places the dates in order: **Effective**, **Term start**, **Term end**, **Notice due**, **Internal action**, and **Audit date**. Click a date to edit it. The **+** beside the track brings back a date you hid. What each date means, and which ones Coverbase calculates, is in [Contract dates and reminders](/user-guides/contract-dates-and-reminders).
* **The grid** under it holds **Effective date**, **Term start**, **Term end**, **Initial term**, **Auto-renews**, **Renewal term**, **Notice period**, **Notice due**, **Contract value**, **Payment terms**, **Services**, and **Description**. Click any value to edit it. A value marked *derived* was calculated from the others, and a small document icon marks a value read from a document. **Yearly breakdown** in the card header splits the contract value year by year.
* **Renewal decision** shows the decision recorded for the current term and who recorded it. **Record decision** (or **Change decision**) opens the four choices, **Not decided**, **Renew**, **Terminate**, and **Under review**, with a note for why and who you asked, and the contract's **Renewal Notes**. The decision is a column on the contracts list and a filter across the portfolio, so "which renewals has nobody decided yet" is a question you can answer without opening records one at a time.
* **Reminders** says how many reminder emails are scheduled and whether they are inherited from the global settings or set for this contract. Click it to see the schedule. Admins see **Configure**.
<Warning>
**A contract set to auto-renew with no renewal term cannot renew.** Renewal needs both: the setting that says it renews, and a term to renew into. With only the first, the contract is marked expired on the term end its paperwork names, which can be years in the past.
**Needs Attention** says so when it applies, and the renewal editor warns you as you set it. Filling in **Renewal term** clears it. The next nightly run then renews the contract and puts its status back.
</Warning>
<Frame>
<img alt="Warning that the contract is set to auto-renew but no renewal term is recorded" />
</Frame>
<Note>
If a contract renews while you are recording a decision about the term that ended, the save is refused and you are told the term moved. That is deliberate: the decision was about the old term, and the new one deserves a fresh look. Read the new term, then record the decision again.
</Note>
### Saving, and undoing a save
**Description** and **Payment terms** save when you click away. There is no **Save** button for them, so the confirmation is the toast that appears in the corner: "Description saved" or "Payment terms saved". **Contract value**, **Services**, and the renewal notes also save as you leave them. The date and renewal editors open in a panel with their own **Save**.
The **Description** and **Payment terms** confirmations carry **Undo**. Click it and the field goes back to the value it held before that save.
<Note>
**Undo is offered for one save at a time.** Once you edit the same field again, the earlier offer disappears, because putting back a value from two edits ago would throw away the edit in between. Finish an edit, check the confirmation, then move on.
</Note>
If a save fails, the toast says so and names the field. The value stays in the box, so you can click away again to retry rather than retyping it.
### The vendor card
<Frame>
<img alt="Vendor card showing other contracts, status, owners, risk tier, and assessment dates" />
</Frame>
The top of the right rail answers the questions that decide how carefully the rest of the page should be read. The same 90 day notice period is routine on a design tool and a board-level problem on the vendor holding your customer data.
| Row | What it tells you |
| - | - |
| **Other contracts** | How many other live agreements you have with this vendor, and what they are worth. Click through to see them. |
| **Relationship owners** and **Risk analysts** | Who to ask. |
| **Risk tier** | The vendor's inherent risk rating. |
| **Last assessment** and **Next assessment** | When you last looked at them, and when you look again. |
Click the vendor name to open the full vendor record.
<Note>
**Unavailable** in the risk tier or last assessment row means the lookup failed, not that the vendor is unrated or never assessed. Reload the page. If it keeps saying **Unavailable**, the vendor record itself will tell you.
</Note>
### The documents tab
<Frame>
<img alt="Documents tab showing the file table above the contract components and document insights cards" />
</Frame>
The **Documents** tab opens on **Files**: every document on the contract, with every action on a row. Upload new files below the list, or use **Link Existing Contract Documents** to add paper already on the vendor. When you upload, Coverbase reads each new file against what the contract already holds and asks you to confirm what it does before anything is saved, for example whether it replaces a document or adds to the contract.
Below the files sit **What the documents say**, the [contract components](/user-guides/contract-components) read by component or by document, and **Document Insights**.
## What's next
<CardGroup>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
Build a clause set, run a review against the documents you choose, and work the results.
</Card>
<Card title="Contract dates and reminders" icon="calendar-days" href="/user-guides/contract-dates-and-reminders">
What each date on the timeline means, which ones Coverbase calculates, and who gets the reminder emails.
</Card>
<Card title="The contract Spend tab" icon="coins" href="/user-guides/contract-spend">
What a contract costs, line by line, and across its renewals.
</Card>
<Card title="Contract Assembly" icon="layer-group" href="/user-guides/contract-assembly">
Import a folder of contracts you already hold and confirm what Coverbase proposes.
</Card>
</CardGroup>
# Corporate registrations guide
Source: https://docs.coverbase.com/user-guides/corporate-registrations
How to read a vendor's legal entity, its group, and the evidence behind them, and how to correct the entity in your own words.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For what the capability is and where it stops, see [Corporate registrations](/products/corporate-registrations).
</Info>
The **Registrations** tab tells you which legal entity stands behind a vendor, what that rests on, and the corporate group around it. Coverbase reads the vendor's own legal pages, looks the entity up in public registers, and shows you every source it used.
It runs on its own once a vendor has a website on file. You do not start it.
## Finding it
Open a vendor, go to **Vendor Intelligence**, and pick the **Registrations** tab.
<Frame>
<img alt="The Registrations tab for Computershare, showing Computershare Limited bound to a register as the head of a group of 19 subsidiaries, tiles for its LEI and ASIC company number, a dashed D-U-N-S tile, and three steps: the vendor record, the copyright line from its website, and the GLEIF record." />
</Frame>
## What the entity rests on
The label above the entity's name says what the identity rests on. Read it before you use any identifier below it.
| Label | What it means | What to do |
| - | - | - |
| **Bound to a register** | A public register holds this entity, and the evidence agrees with your vendor. | Use the identifiers. They are safe to quote in a questionnaire. |
| **Identified from the vendor's own pages** | No open register holds the entity, but the vendor names it on its own legal pages. | Read the quotes. Confirm the entity, add its registration number, or ask the vendor. |
| **Confirmed by your team** | Someone in your organization named or picked the entity. | Nothing. Every refresh keeps it. |
| **Match result: needs review** | Several registered companies could be your vendor. | Pick the right one from **Possible matches**. |
| **Recorded by your team** | Someone in your organization recorded that no registered entity stands behind the vendor. | Nothing. Coverbase stops searching the registers under its name. |
| **No registry match** | Nothing credible matched, and the vendor's pages name no entity. | Normal for small, new, or non-corporate suppliers. Use **Correct with AI** if you know the entity, or **Mark as no registered entity** if there is none. |
## How Coverbase finds the entity
Coverbase looks for the entity the way you would if you searched for it yourself.
<Steps>
<Step title="Read the vendor's own legal pages">
The terms, privacy policy, imprint and site footer name the company a customer contracts with, often with its registration number, its former names and its subsidiaries. Coverbase reads them and keeps the passage each entity came from. A company named only in passing, such as a payment provider or a hosting company, is ignored.
</Step>
<Step title="Look the entity up by its number">
When the vendor states a registration number, Coverbase looks it up directly in GLEIF and Companies House. The record is bound only when its name agrees with the one the vendor states.
</Step>
<Step title="Search the registers by name">
Coverbase searches GLEIF, Companies House, OpenCorporates and SEC EDGAR for the stated legal name, the vendor's name and its former names. A record that carries the exact legal name the vendor states wins over one that only shares its brand. A record in another country than the vendor's is offered for review, not bound.
</Step>
<Step title="Fall back to the vendor's word">
When no register holds the entity, the page shows the entity the vendor names, marked **Identified from the vendor's own pages**, with the quotes. It stays unvalidated until you confirm it.
</Step>
</Steps>
<Frame>
<img alt="The Registrations tab for PostHog, identified from its own privacy policy as PostHog Inc., formerly Hiberly Inc., with Hiberly Ltd on Companies House and PostHog GmbH named by the vendor." />
</Frame>
## Identifiers
Under the verdict, each identifier has a tile: the LEI, the company number with the register that issued it, the SEC CIK, and the D-U-N-S number. A dashed tile is one no register returned.
* **Add a D-U-N-S number** saves the number Dun & Bradstreet assigns to the vendor.
* **Add a file number**, **Add HRB number** or **Add company number** appears when the entity rests on the vendor's word. Coverbase looks the number up wherever the home register is open.
When a register holds the entity, **How we identified it** shows the three steps that got there: your vendor record, the passage on the vendor's own pages, and the register record. Each step links to its source.
## Confirm an entity the vendor names
When the entity is **Identified from the vendor's own pages**, **What would confirm it** lists the evidence that would settle it.
* **Confirm** saves the entity as your team's, for example once you have checked it against your signed contract.
* **Ask the vendor** drafts a message asking which entity contracts with you and for its registration number. **Request a certificate of incorporation** drafts a request for the certificate. Edit the message, copy it, and send it from your own mail.
## Organization structure
**Organization structure** shows the vendor's parents above it and its subsidiaries below it. Each entity shows its country, its identifiers, and where it is known from:
* **GLEIF** or **Companies House**: a register holds the entity and reports the relationship.
* **Named by the vendor**: only the vendor's own pages mention the entity. Treat the link as the vendor's statement. Click **Add HRB number** (or the number its country uses) to add its registration number.
When a group has many subsidiaries, filter them by country. GLEIF lists at most 25 here, and the heading gives the register's total.
## Choose among possible matches
When several registered companies share your vendor's name, **Possible matches** lists them, ranked by what agrees besides the name: the state or country, the city, and the industry. Click **Use this entity** on the right one. The page binds it at once, and every later refresh keeps your choice.
If none of them is your vendor, click **Correct with AI** to name the right entity, or **Mark as no registered entity** when the vendor has none, such as a sole trader or an open-source project.
<Frame>
<img alt="The Possible matches section for Mercury, with Mercury Technologies, Inc. marked best fit, Mercury Systems, Inc. and Mercury NZ Limited beside it, each with a Use this entity button." />
</Frame>
## Correct with AI
Use **Correct with AI** when the entity is wrong or missing. You describe the right entity in your own words, and you see the match before anything changes.
1. Click **Correct with AI** in the verdict.
2. Describe the entity. For example: "Our contract is with PostHog's UK company, Hiberly Ltd." You can also paste a registration number, an LEI, or the signature block from your contract.
3. Click **Find the entity**. Coverbase reads your note, searches the registers, and shows what it found and the proposed change.
4. Click **Apply** to save it, or **Not right, try again** to edit your note.
5. The panel confirms the change. Click **Back to registrations**, or **Undo** to put the previous entity back.
<Frame>
<img alt="The Correct the Registration panel after Apply, reading HIBERLY LTD is now the legal entity, with Back to registrations and Undo buttons." />
</Frame>
<Frame>
<img alt="The Correct the Registration panel, showing the reviewer's note, three checked steps, and a proposed change from PostHog Inc. to HIBERLY LTD, company number 12082013, on a register." />
</Frame>
You need permission to edit the vendor. The correction applies to every organization that shares the vendor's company record.
## Undo a change
Every change you make on the page, a picked match, a confirmed entity, an added number, or a correction, shows a banner at the top with **Undo**. Undo restores what your team had confirmed before, or returns the vendor to what the evidence alone shows.
<Frame>
<img alt="A green banner reading Bound to Mercury Technologies, Inc., saved so the next scheduled check keeps it, with an Undo button, above the Mercury match result." />
</Frame>
## Registered address
The address on the register is the vendor's legal address, not where its people work. A registered agent's or accountant's address is normal and is not a red flag by itself.
## What to do with a dissolved status
A **dissolved** status on a vendor you are paying needs attention. It usually means a restructure moved the business to another entity, or the company on your contract no longer exists. Ask procurement which legal entity is on the current contract, and compare it to the registered name on this page.
## Troubleshooting
| Symptom | Fix |
| - | - |
| The page says no registration record yet | The vendor has no website on file. Add one, and the check runs on the next refresh. |
| The legal name differs from the name you use | Trading names and registered names often differ. The **Also known as** list shows both. |
| A private US company stays **Identified from the vendor's own pages** | US state registers are not open to search, so the entity cannot be checked against one. Confirm it, or ask the vendor for its state file number. |
| The vendor's pages name no entity | Some sites block automated reading or build their pages in the browser. Use **Correct with AI** with the entity on your contract. |
| A match was bound but you disagree | Use **Correct with AI** and name the right entity. |
| A US vendor has no CIK | Only public filers have one. Its absence says nothing about the company. |
## Related
<CardGroup>
<Card title="Global financial coverage" icon="earth-americas" href="/user-guides/global-financial-coverage">
How the bound entity decides which filings Coverbase reads.
</Card>
<Card title="Zero Touch Assessments" icon="bolt" href="/user-guides/zero-touch-assessments">
Registration standing as a scored component.
</Card>
</CardGroup>
# Dark web monitoring guide
Source: https://docs.coverbase.com/user-guides/dark-web-monitoring
How Coverbase watches your organization and your vendors on ransomware leak sites, breach catalogs, infostealer logs and lookalike domains, which sources need a license, and how to triage the exposure queue.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Dark Web** in the left navigation, the **Dark Web** tab in a vendor's [Vendor Intelligence](/products/vendor-intelligence), and the settings under **Configuration → Monitoring → Dark Web**. For news, advisories and regulator filings about your vendors, see the [Radar signals guide](/user-guides/radar-signals) and the [Breach notification monitoring guide](/user-guides/breach-notification-monitoring). For the neighboring Vendor Intelligence tab that checks sanctions and watchlists, see the [Sanctions screening guide](/user-guides/sanctions-screening).
</Info>
<Note>
Dark web monitoring is an optional module. If you do not see **Dark Web** in the left navigation, ask your Coverbase account team to turn it on.
</Note>
Dark web monitoring checks your organization and your vendors against services that track what criminals publish and register: ransomware groups' leak sites, published data breaches, logs from infostealer malware, and newly registered domains built to look like a real one. It runs once a day. Every hit becomes an **exposure** in one queue, and a person decides what it means.
Each source is an outside service that already follows one kind of criminal activity and makes it searchable. Coverbase asks each source about the names and domains on your watchlist. It keeps the facts the source returns: who listed the company, when, how many records, which kinds of data. The leaked content itself, such as passwords or personal data, is never stored.
The mistake people make most often is reading an empty queue, or a vendor tab marked **Clear**, as proof that nothing was found. Out of the box only the vendors Radar monitors are watched. A vendor tab shows **Clear** only when the vendor has watched values, a sweep has checked them, and nothing is open. Otherwise it shows **Not watched** or **Not checked yet**. See [The vendor's Dark Web tab](#the-vendors-dark-web-tab).
## Where it lives
Three places, for three jobs.
**The queue**: **Dark Web** in the left navigation. Every exposure for your organization and every watched vendor, worst first, with the watchlist and the sweep history on tabs beside it. This is where triage happens.
**On a vendor**: open a vendor, choose **Vendor Intelligence**, then **Dark Web**. The same exposures for that vendor only, with the values being watched for it.
**The settings**: **Configuration → Monitoring → Dark Web**, or **Configuration** at the top right of the queue. An administrator switches monitoring on here and decides who is watched and which sources run.
## What is watched
The sweep checks a watchlist. You do not type most of it: Coverbase builds it from records you already keep, and rebuilds it at the start of every sweep.
**Your organization.** Its names, the domain of its website, and its email domains, all read from your organization record. **Monitor our organization** is on by default.
**Your vendors.** For each vendor in scope, the vendor's name and the domain of its website. When the vendor is linked to an entry in the Coverbase directory, that company's name, website and other known names are added too.
**Every website domain is also watched as an email domain.** Breach and infostealer data is organized by the address people sign in with, and a company's web domain is usually its mail domain. If it is not, switch that row off.
Values are normalized before they are stored, so different spellings of one value share a row. Case, accents, punctuation, a leading `www.` and a trailing company suffix such as Inc, Ltd or Co are ignored, which makes `Orchard Insurance` and `Orchard Insurance Co.` one row.
Which vendors are in scope is a setting, and it is the one to check first.
| Setting | Who is watched |
| - | - |
| **Vendors monitored in Radar** (the default) | Only vendors with Radar monitoring switched on, the same vendors Radar already watches. A workflow's **Enable vendor threat monitoring** action turns it on for a vendor; see [Which vendors are watched](/user-guides/radar-signals#which-vendors-are-watched). |
| **All vendors** | Every vendor that is not archived. More values, so more lookups per sweep. |
| **No vendors** | Only your organization. |
Archived vendors are never watched. A vendor that leaves the scope drops off the watchlist at the next sweep. The exposures already found for it stay in the queue.
## What each source checks
A sweep consults five sources. Each one reads only some kinds of watchlist value, and each raises one category of exposure at a severity set by fixed rules.
| Source | What it looks for | Reads | Raises |
| - | - | - | - |
| **RansomLook** | Victim listings on ransomware groups' leak sites: the last 30 days, plus a search of older listings for your watched names and domains | Company names, domains | **Ransomware victim**, always **Critical** |
| **ransomware.live** | The same kind of listings, from a second tracker. Needs a license; see below. | Company names, domains | **Ransomware victim**, always **Critical** |
| **Have I Been Pwned** | Breaches of the service run on a domain, from its public breach catalog. It does not search for employees' accounts caught up in other companies' breaches. | Domains and email domains, **your organization's only** | **Data breach**: **High** when passwords were exposed, otherwise **Medium** |
| **Hudson Rock** | How many computers infected with infostealer malware held credentials for the domain, split into employees and users | Domains, email domains | **Stealer infection**: **High** when any employee's computer is infected, otherwise **Medium** |
| **Lookalike domains** | Variations of a watched domain that someone has registered and that resolve: the same name under another ending, added words such as `-login`, look-alike characters, hyphens and common typos | Domains | **Brand impersonation**: **Medium** when the lookalike can receive mail, otherwise **Low** |
Lookalike checks cover your organization's own domains. Vendor domains are added only when **Lookalike domains for vendors** is on.
### Sources that need a license
**ransomware.live** does not allow commercial use without its written approval and a licensed key. Coverbase holds that key for the whole platform, not per organization, so there is no field for your own. Until the key is in place, the source's switch stays off and shows **Needs a platform key**, and every sweep lists it as skipped in **Sweep History**. Once the key exists, the source runs without any change on your side.
**Have I Been Pwned** is used for your organization's own domains only. Vendor domains are not sent to it, so a vendor never has a **Data breach** exposure. For a vendor's known breaches, read [Breaches and exposed credentials](/user-guides/security-intelligence#breaches-and-exposed-credentials) on its **Security** tab.
**RansomLook** and **Have I Been Pwned** publish under the CC BY 4.0 license, which requires credit. Every exposure from them names the source and links back to it.
### Large portfolios
Each sweep searches the ransomware trackers' older listings for at most 150 names and domains, and checks at most 25 domains for lookalikes. Your organization's values go first in both. Recent leak-site listings are matched against the whole watchlist. Each source also has a few minutes per sweep, and one that runs out of time keeps what it found. Its badge in **Sweep History** turns amber, and the values it did not reach keep their earlier **Last Checked** time. Lookalike checks work through the vendors' domains over the following days, 25 domains per sweep, your own first. With **All vendors** on a large portfolio, keep this in mind before you read a quiet queue as full coverage.
### What no source reads yet
<Warning>
The sources read three types of value: **Company name**, **Domain** and **Email domain**, so those are the types **Add asset** offers. An older **Person name**, **Email address**, **Card BIN** or **Keyword** row stays on the watchlist and reads **Not searched**, as does a company name too short or generic to match on its own, such as "SAP". The queue's category filters list only the categories a current source raises.
</Warning>
## Switching it on
Do this once, as an administrator. Open **Configuration → Monitoring → Dark Web**.
<Frame>
<img alt="The Dark Web configuration page showing the Status card with the Monitoring badge, the enable switch, 117 assets on the watchlist across 28 vendors, Not swept yet, Open the queue and Sweep now, then the Your Organization card with company names, no domains, two email domains and a note on where they come from, and the Vendors card with Vendors monitored in Radar selected and 28 vendors matching that choice." />
</Frame>
1. Under **Your Organization**, read the **Company names**, **Domains** and **Email domains**. They come from your organization record: its names, the domain of its **Website**, and its email domains. Change the name and website under **Organization settings** (the link on the card). Email domains are set when Coverbase creates your organization; to change them, ask your Coverbase account team, or switch an unwanted one off on the watchlist.
2. If **Domains** reads *None on the organization record.*, your organization has no website on file. Leak-site matching on your domain and lookalike checks then have nothing to work with for your organization, so add the website first.
3. Under **Vendors**, choose who is watched. Read the count underneath, **N vendors currently watched.**, before you rely on the queue.
4. Leave **Lookalike domains for vendors** off unless you need it. It adds every watched vendor's domain to the lookalike checks, and each sweep checks at most 25 domains.
5. Under **Sources**, leave switched on the sources you want consulted. Every source that can run is on by default.
6. Under **Status**, switch on **Enable dark web monitoring**.
<Frame>
<img alt="The lower half of the Dark Web configuration page: the Vendors card with its three scope options, 28 vendors matching the choice and the Lookalike domains for vendors switch, and the Sources card with RansomLook, Have I Been Pwned, Hudson Rock and Lookalike domains switched on and ransomware.live switched off with a Needs a platform key badge." />
</Frame>
Every change on this page saves as you make it and rebuilds the watchlist straight away, so the counts under **Status** and **Vendors** update. The first sweep happens at the next daily run, at 06:20 UTC. **Sweep now** runs it immediately.
The **Status** card also reports trouble. **The last sweep reported an error** appears, with the error, when every source failed on the last sweep. It clears after the next sweep in which a source works.
## How an exposure arrives
Every day at 06:20 UTC, Coverbase sweeps each organization that has monitoring on. A sweep does three things:
1. It rebuilds the watchlist from your organization and vendor records, so a vendor that joined the scope yesterday is checked today.
2. It asks every switched-on source about the watchlist values that source reads.
3. It records what came back as exposures, stamps each watched value with the time, and adds a row to **Sweep History**.
**Sweep now**, on the queue or on the settings page, runs a sweep immediately. Only one sweep runs at a time for your organization, and a second click reports that one is already running. While a sweep runs, **Last sweep** reads **Running**, and the tables refresh when it finishes.
Three rules keep the queue from filling with repeats and near misses:
* **One exposure per listing.** The same listing found again on a later sweep does not create a new exposure. It moves **Last Seen**, adds to the **seen N times** count, and refreshes the evidence.
* **Your decision sticks.** A new sighting never changes an exposure's status. An exposure you resolved stays resolved even if the source keeps reporting it; its **Last Seen** keeps moving on the **Resolved** list.
* **Names match cautiously.** On a leak-site listing, a domain is the strongest match. A company name matches only as a whole phrase. A name shorter than four characters, or one made only of generic words such as "Global Systems", never matches on its own, so the domain has to appear in the listing.
## The exposure queue
Open **Dark Web** in the left navigation.
<Frame>
<img alt="The Dark Web page with five counters (Open exposures, Critical and high, Organization / Vendors, New in the last 7 days, and Last sweep reading Never with 117 assets and 28 vendors), the Exposures, Monitored Assets and Sweep History tabs, the Configuration and Sweep now buttons, the Open and Resolved buttons, severity and subject filters, four category filters, a search box, and an empty table reading No sweep has finished yet, so nothing has been checked." />
</Frame>
Five counters sit at the top.
| Counter | What it counts |
| - | - |
| **Open exposures** | Exposures in **New**, **Acknowledged** or **Investigating** |
| **Critical and high** | Open exposures at **Critical** or **High** |
| **Organization / Vendors** | Open exposures about your organization, then about vendors |
| **New in the last 7 days** | Exposures first found in the past week, whatever their status |
| **Last sweep** | When the last sweep finished, **Running** during one, or **Never**. A sweep in which every source failed does not count. Underneath: how many values and vendors are watched. |
Below them are three tabs, **Exposures**, **Monitored Assets** and **Sweep History**, with **Configuration** and **Sweep now** at the right. You see those two buttons only if your role can change the settings and run sweeps.
The **Exposures** table shows **Severity**, **Exposure** (the title, with the threat actor underneath when the source names one), **Subject** (**Organization** or the vendor), **Category**, **Source**, **First Seen**, **Last Seen**, **Status** and **Assignee**. It is sorted worst severity first, then most recently seen, 50 to a page by default.
### Narrowing the queue
* **Open** and **Resolved** switch between exposures still being worked (**New**, **Acknowledged**, **Investigating**) and closed ones (**Resolved**, **False positive**).
* The severity buttons (**Critical**, **High**, **Medium**, **Low**, **Info**), **Organization** and **Vendors**, and the category buttons below them filter the list. Click a button to apply it and again to clear it. Buttons of the same kind widen the list; buttons of different kinds narrow it.
* **Search exposures** matches the exposure title, the matched term, the threat actor and the vendor's name.
The filters reset when you leave the page. The **Open** or **Resolved** choice and an open exposure are kept in the page address, so you can send a colleague a link to one exposure.
## Reading an exposure
Click a row to open the exposure in a panel on the right. The header names the subject (your organization, or the vendor with a link to its page), the title, the severity, the status, and the category and source.
**What Matched** holds the facts:
| Field | What it tells you |
| - | - |
| **Matched Term** | The watched value the source matched, with a confidence: 100% when the source was asked about the domain itself, 95% when a leak-site listing names the domain, 80% when it names the company |
| **Monitored Asset** | The watchlist row that matched, and its type |
| **Threat Actor** | The ransomware group, on a leak-site listing |
| **Data Classes** | The kinds of data exposed in a breach |
| **Records** | The accounts in a breach, or the infected computers for an infostealer exposure |
| **Published** | The date the source gives: the listing, the breach, or the latest infection |
| **First Seen**, **Last Seen** | When Coverbase first and most recently found it, and how many times |
| **Source Link** | The source's own page for it |
Below it, **Summary** is the source's description, with anything that looks like a credential, an email address, a card number or a key masked. **Evidence** lists what else the source returned: counts, malware families, dates and references.
What to check first depends on the category:
| Category | Title reads | Check first |
| - | - | - |
| **Ransomware victim** | `<victim> listed on the <group> leak site` | Whether the listed victim really is this company. Look at **Matched Term** and its confidence, then the listing through **Source Link**. A match on the company name alone is the likeliest false positive. |
| **Data breach** | `<breach> breach affecting <domain>` | The breach date under **Published**, and whether **Data Classes** include passwords. |
| **Stealer infection** | `Infostealer infections recorded for <domain>` | In **Evidence**, how many employee and user computers were infected, and when the latest infection was. An employee infection means staff credentials for that domain were captured. |
| **Brand impersonation** | `Lookalike domain registered: <domain>` | Whether the **Summary** says it can receive mail. A lookalike that can receive mail can carry phishing or invoice fraud aimed at people who trust the real domain. |
## Triaging an exposure
Decide what each exposure means and record it, so the next person does not check it again.
1. Open the exposure from the queue or from the vendor's tab.
2. In **Triage**, set the **Status**, pick an **Assignee** if someone will follow it up, and write a **Note**: what was checked, and what was decided.
3. Click **Save review**. The panel closes and the queue updates.
From then on the panel shows **Last reviewed by**, with the name and time of the last save.
| Status | Use it when | Listed under |
| - | - | - |
| **New** | Nobody has looked yet. Every exposure arrives here. | **Open** |
| **Acknowledged** | You have seen it and someone owns it. | **Open** |
| **Investigating** | Someone is checking whether it is real and what it touches. | **Open** |
| **Resolved** | It has been dealt with, or checked and found to need no action. | **Resolved** |
| **False positive** | The listing is not about this organization or vendor. | **Resolved** |
Any status can follow any other, which is how you reopen a closed exposure. Nothing moves an exposure between statuses on its own, and there is no delete: an exposure leaves the open list only through its status.
### Escalating to a finding
When an exposure needs work tracked with an owner and a due date, click **Escalate to finding**. Coverbase opens a finding:
* Titled with the exposure's title, with the source type **Dark web exposure**.
* With a description that lists the source, category, severity, matched term, threat actor and reference link, followed by the summary.
* Assigned to the exposure's saved assignee, if it has one.
* On the vendor, for a vendor's exposure. An exposure about your organization gives a finding with no vendor.
The button then reads **Open finding**. An exposure has at most one finding, and on the **Findings** list the finding's **Source** column links back to the exposure. From there it is an ordinary finding; see [Findings and remediation](/user-guides/findings-and-remediation).
Escalating does not change the exposure's status, and it does not save what you changed under **Triage**. Save the assignee first if the finding should go to them, and set the status and click **Save review** afterwards.
## Keeping the watchlist right
Make sure the sweep checks the right values, and nothing that belongs to someone else. Open **Dark Web**, then **Monitored Assets**.
<Frame>
<img alt="The Monitored Assets tab listing rows with Subject, Type, Value, Source, Enabled, Open Exposures and Last Checked columns: the organization's company name and two email domains with gmail.com switched off, then company name, domain and email domain rows for vendors such as Honeywell and Zebra Technologies, all Derived, with gmail.com marked Not watched and the rest Not checked yet, with Search assets, Re-derive and Add asset controls." />
</Frame>
Each row shows its **Subject**, **Type**, **Value**, **Source** (**Derived** from a record, or **Manual** when someone added it), **Enabled**, **Open Exposures** and **Last Checked**. **Search assets** matches values and vendor names.
* **Switch a row off** with its **Enabled** switch to stop checking it. Use it for a value that is not really yours or the vendor's, such as a shared mail provider on the organization record, or a company name that is also an ordinary word. A derived row cannot be removed, because the next rebuild would only add it back. Switched off, it stays off.
* **Derived rows look after themselves.** When a record stops producing a value, because a vendor left the scope or was archived or a website changed, the row leaves the watchlist at the next rebuild. Exposures already found stay in the queue.
* **Re-derive** rebuilds the derived rows now instead of at the next sweep, and reports how many were added, kept and retired. Use it after you change a vendor's website or turn on Radar monitoring for more vendors. Changing a setting on the configuration page rebuilds the watchlist too.
* **Add asset** watches a value no record provides, such as a second brand's domain or the domain a vendor runs its customer portal on. Choose what it **Belongs To** (**Organization**, or **Vendor** and then the vendor), its **Type** and its **Value**. It is checked from the next sweep on.
* **Remove**, the bin icon at the end of a manual row, stops watching that value. Exposures already found for it stay in the queue.
<Frame>
<img alt="The Add Monitored Asset dialog with Belongs To set to Organization, Type set to Domain, an empty Value field with example.com as its placeholder, a note that spelling, case and punctuation are normalized, and the Cancel and Add asset buttons." />
</Frame>
**Last Checked** is the time of the last sweep in which a source that reads that value finished checking it. A value whose only sources failed, or ran out of time, keeps its earlier time. **Not searched** means no current source can check the value.
## Sweep history
Open **Dark Web**, then **Sweep History**. There is one row per sweep, scheduled or manual, including sweeps that found nothing.
| Column | What it shows |
| - | - |
| **Started** | When the sweep began |
| **Status** | **Running**, **Completed**, **Partial** (at least one source failed and the others ran) or **Failed** (every source that ran failed). Hover a **Partial** or **Failed** status for the error. |
| **Trigger** | **Scheduled**, or **Manual** with the name of whoever clicked **Sweep now** |
| **Assets Checked** | The watchlist values in the sweep |
| **New Exposures** | Exposures found for the first time |
| **Sources** | One badge per source: green when it ran, gray when it was skipped, red when it failed. Hover a badge for how many values it checked and how many candidates it returned, or for its error. |
A source is skipped when it has no key, as ransomware.live does until Coverbase licenses it, or when the watchlist holds nothing it can read. A source switched off in the settings is not listed at all.
A failed source reads as failed, never as clean. The other sources' results still count, and the next sweep tries it again.
## The vendor's Dark Web tab
See one vendor's exposures without the rest of the queue. Open a vendor, choose **Vendor Intelligence**, then **Dark Web**.
<Frame>
<img alt="The Dark Web tab on a vendor page, under Vendor Intelligence, with Not checked yet at the top right, an Open Exposures section showing a Not checked yet badge and No open exposures, and a Monitored Assets section listing the vendor's company name, a company-name alias, its domain and its email domain, each Derived and Not checked yet." />
</Frame>
* **Last checked**, at the top right, is the oldest check across the vendor's watched values. It reads **Not checked yet** for a watched vendor before its first sweep, and **Not watched** when nothing a source can search is watched for the vendor.
* **Open Exposures** lists everything open for the vendor, with a count per severity. With nothing open it shows **Clear** once a sweep has checked the vendor's watched values, **Not checked yet** before that, and **Not watched** when nothing searchable is watched for the vendor.
* **Monitored Assets** lists the values watched for this vendor, each with its type, **Derived** or **Manual**, **Disabled** when switched off, and when it was last checked. A value with open exposures shows how many are open.
* **Resolved** lists closed exposures, and appears only when there are some.
Click an exposure to open the same panel as on the queue, with the same triage and escalation. The tab lists up to 50 open exposures, 50 resolved ones and 50 watched values; for more, search the vendor's name on the **Dark Web** page. To add or switch off a vendor's values, use **Monitored Assets** on the **Dark Web** page.
<Warning>
**Clear** means a sweep checked the vendor's watched values and nothing is open. It is still only as wide as the sources: before you write "no dark web exposure" into an assessment, check what **Monitored Assets** lists and when **Last checked** ran.
</Warning>
<Frame>
<img alt="The Dark Web tab on a vendor that is not in scope, showing Not watched at the top right and as the Open Exposures badge, No open exposures, and a Monitored Assets note that nothing is being watched for this vendor and how a vendor comes to be watched." />
</Frame>
If the tab reads **Dark web monitoring is off**, monitoring is switched off for your organization.
The tab is part of the newer vendor page, where **Vendor Intelligence** lists its tabs down the left. If your vendor pages have tabs across the top instead, search the vendor's name on the **Dark Web** page. Reviewers also find the tab under **Vendor Intelligence** when they open a questionnaire submission from the vendor.
| | **Dark Web** page | A vendor's **Dark Web** tab |
| - | - | - |
| Covers | Your organization and every watched vendor | One vendor |
| Exposures about your organization | Yes | No |
| Triage and escalation | Yes | Yes, in the same panel |
| Watchlist | View, add, switch off, **Re-derive** | View only |
| **Sweep History** and **Sweep now** | Yes | No |
| How many exposures | All of them, a page at a time | Up to 50 open and 50 resolved |
## Notifications
Dark web monitoring sends no email and no in-app notification. A new exposure appears in the queue and on the vendor's tab and nowhere else, so someone has to look. The daily sweep runs at 06:20 UTC, so one check a day after that time catches each day's new exposures.
To route new exposures automatically:
* **Workflows.** **Dark Web Exposure** is a trigger record with **Created**, **Updated** and **Deleted** events. See [Building a workflow](/user-guides/building-a-workflow#when-the-trigger).
* **Webhooks.** `DarkWebExposure.Created`, `DarkWebExposure.Updated` and `DarkWebExposure.Deleted` carry `dark_web_exposure_id`. Created and Updated also carry the type, severity, subject, deadline and masked identifier described in the [dark web exposure payload](/api-reference/webhooks#dark-web-exposure-payload), never leaked content. See the [event catalog](/integrations/webhooks#event-catalog).
An exposure you escalate becomes a finding, and from then on it follows the findings workflow, including [its notifications](/user-guides/findings-and-remediation#emails-and-notifications).
## Not the same as Radar or the Security tab
Three parts of Coverbase deal with breaches or the dark web. They do not share a queue, and nothing found by one appears in the others.
| Where | What it is | Worked in |
| - | - | - |
| **Dark Web** (this guide) | A daily sweep of your watchlist against leak-site trackers, breach and infostealer data, and lookalike domains | The **Dark Web** queue |
| Radar's **Dark Web and Underground Exposure** detector | A [Radar detector](/products/detector-library) that reads Radar's own sources for vendor data, access or credentials advertised on criminal forums | **Radar → Signals** |
| A vendor's **Security** tab | [Breaches and exposed credentials](/user-guides/security-intelligence#breaches-and-exposed-credentials) and [Lookalike domains](/user-guides/security-intelligence#lookalike-domains), as part of the vendor's outside-in rating | The rating itself, from which you can open a finding |
## Who can do what
Dark web monitoring has its own permission, listed as **Dark web exposure** in the role editor. Like other vendor-backed permissions, it needs vendor read alongside it.
| Permission | Allows |
| - | - |
| `dark_web_exposure:read` | See the **Dark Web** page, a vendor's **Dark Web** tab and each exposure |
| `dark_web_exposure:update` | Triage and escalate exposures; add, switch off and remove watchlist values; **Re-derive**; open and change **Configuration → Monitoring → Dark Web** |
| `dark_web_exposure:run` | **Sweep now** |
| Default role | Access |
| - | - |
| **Admin** | Everything above |
| **Member**, **Guest** | Read. They see the queue, the vendor tab and each exposure, but no **Triage** section, no **Sweep now** and no settings. |
| **Siloed Member**, **Auxiliary Member** | None. **Dark Web** and the vendor tab do not appear. |
Exposures follow vendor access. A role that can read only some vendors sees those vendors' exposures, plus every exposure about your organization. The counters at the top of the queue still count the whole organization. Custom roles are built in [Permissions and roles](/user-guides/permissions-and-roles).
## Troubleshooting
| Symptom | Cause | Fix |
| - | - | - |
| **Dark Web** is missing from the left navigation | The module is off for your organization, or your role has no dark web permission | Ask your Coverbase account team to turn it on. If colleagues can see it, ask an admin for `dark_web_exposure:read`. |
| The queue is empty and **Last sweep** reads **Never** | No sweep has run since monitoring was switched on | Wait for the 06:20 UTC sweep, or click **Sweep now**. |
| A vendor's tab shows **Not watched** | The vendor is outside the vendor scope | Turn on Radar monitoring for it, choose **All vendors**, or add a value for it with **Add asset**. |
| The settings page reads **0 vendors currently watched.** | The scope is **Vendors monitored in Radar** and no vendor has Radar monitoring on, or no setting has been saved yet | Switch monitoring on, which builds the watchlist. If the count stays at 0, choose **All vendors** or turn on Radar monitoring for your vendors. |
| Your organization's **Domains** reads *None on the organization record.* | Your organization record has no website | Add the website under **Organization settings**. |
| **Sweep now** is grayed out on the settings page | Monitoring is off, or a sweep is running | Switch on **Enable dark web monitoring**, or wait until **Last sweep** stops reading **Running**. |
| **Sweep now** reports that a sweep is already running | One sweep runs at a time per organization | Wait for it to finish. The tables refresh on their own. |
| **Sweep now** is grayed out on the queue, under a *Dark web monitoring is off* notice | Monitoring is off | Switch it on in **Configuration**. |
| **Sweep now** says the sweep was requested | The background worker did not confirm the start | Nothing to do. The sweep starts when the worker picks it up. |
| ransomware.live is off and shows **Needs a platform key** | It needs a commercial license that Coverbase holds for the platform | Nothing to set on your side. Ask your account team if you need it. |
| **The last sweep reported an error** on the settings page | Every source failed on the last sweep | Open **Sweep History** and hover the red badges. The message clears after the next sweep in which a source works. |
| A badge in **Sweep History** is red | That source failed on that sweep | Hover it for the error. The other sources' results count, and the next sweep retries it. |
| A resolved exposure's **Last Seen** keeps moving | The source still reports it, and your decision is kept | If the new sightings matter, set it back to **Investigating**. |
| An exposure is about a different company with the same name | A leak-site listing matched your watched company name, not the domain | Mark it **False positive**. If the name is an ordinary word, switch that **Company name** row off and rely on the domain. |
| **Add asset** confirmed the value, but its row is still switched off | The value was already on the watchlist, and adding it again leaves that row as it was | Switch the existing row on. |
| A watchlist row reads **Not searched** | No current source reads that type of value, or the name is too short or generic to match | Add the vendor's or your own domain instead. See [What no source reads yet](#what-no-source-reads-yet). |
| The **Triage** section and **Save review** are missing | Your role can read exposures but not update them | Ask an admin. Members have read access by default. |
| The counters show more exposures than the table | The counters cover the whole organization; the table shows only the vendors your role can read | Expected. |
## Related
<CardGroup>
<Card title="Sanctions screening guide" icon="scale-balanced" href="/user-guides/sanctions-screening">
The neighboring Vendor Intelligence tab: sanctions and watchlist matches, re-checked on a schedule.
</Card>
<Card title="Working Radar signals" icon="satellite-dish" href="/user-guides/radar-signals">
Which vendors Radar monitors, which is also who dark web monitoring watches by default.
</Card>
<Card title="Findings and remediation" icon="flag" href="/user-guides/findings-and-remediation">
What happens to an exposure once you escalate it to a finding.
</Card>
<Card title="Security intelligence guide" icon="shield-halved" href="/user-guides/security-intelligence">
A vendor's breaches and lookalike domains as part of its outside-in rating.
</Card>
</CardGroup>
# Exporting and scheduling dashboards
Source: https://docs.coverbase.com/user-guides/dashboard-exports
Export a dashboard to PDF or Excel, or email it on a schedule: what each file contains, how dates and filters apply, how each chart type comes out, who can manage a schedule, and what recipients receive.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers getting a dashboard out of Coverbase, as a file or as a recurring email. To build the dashboard first, see [Dashboards and the chart library](/user-guides/dashboard-library). For assessment reports rather than dashboards, see the [Reporting overview](/reporting/overview).
</Info>
A dashboard leaves Coverbase three ways: as a PDF, as an Excel workbook, or as an email that goes out on a schedule. All three start from the dashboard's row on the **Dashboards** list, not from the open dashboard, and all three read live data at the moment they run.
The mistake people make most often is assuming a schedule keeps its recipients in step with who has access. It does not. A schedule sends to exactly the addresses typed into it, and someone who leaves your organization or loses their Coverbase account keeps receiving the dashboard until you remove their address.
## Where the export options are
Open **Dashboards** in the left navigation. Each dashboard's row ends with an actions menu (**⋮**) that holds:
* **Export**, which opens **Export as PDF** and **Export as Excel**
* **Schedule export**, which opens that dashboard's schedule
<Frame>
<img alt="The Dashboards list with the actions menu open on the Strategic Sourcing Overview row, showing Export with Export as PDF and Export as Excel, then Schedule export, Default and Delete" />
</Frame>
The open dashboard has no export button of its own. If you can export dashboards, each chart's menu there offers **Export data as CSV**, which downloads that chart's figures, and **Download as PNG**, which saves the chart as an image. The CSV's columns carry the same names as the chart's table, money is written to the cent without a currency sign so a spreadsheet can add it up, and cycle times are in hours. If the file cannot be built, a message says so.
## Exporting to PDF or Excel
Use a file for a one-off copy: a board pack, an attachment to a ticket, a spreadsheet to pivot.
<Steps>
<Step title="Choose the format">
On **Dashboards**, open the row's actions menu, point to **Export**, and choose **Export as PDF** or **Export as Excel**.
</Step>
<Step title="Name the file">
**Export file name** starts as the dashboard's name. Change it if you like. The extension is added for you.
</Step>
<Step title="Generate it">
Click **Generate File**. The dialog shows progress while Coverbase builds the file in the background.
</Step>
<Step title="Download it">
When the file is ready, click **Download**. If you closed the dialog, a notification in the **Notifications** menu says the report is ready and carries the same **Download** button. An email follows too if **Report ready for download** is switched on in your notification settings.
</Step>
</Steps>
If the dialog says "Encountered an error while generating the file", close it and try again.
Exporting needs the dashboard export permission, which Admins have. Without it, the **Export** submenu and the chart export items do not appear.
### What the PDF contains
* A title block: the dashboard's name, its description if it has one, and the date and time the file was generated, in your time zone.
* One section per chart: the chart's name as a heading, then the chart drawn across the full width of a US Letter page.
Charts come out one after another in the order you read the grid: top to bottom, and left to right within a row. A chart not yet placed on the grid comes last. Interactive filter widgets are left out, since they hold no data. The PDF draws charts in its own style, so a color theme or density picked on the dashboard does not carry over.
Values read as they do on the dashboard. Supplier tiers, statuses and other groupings show their names, such as **Tier 1 (Critical)**, never an internal key. Money shows with its currency sign: a KPI reads **$130.7M**, and a table cell gives the full amount, such as **$1,249,936**. Cycle times (median, average and 95th percentile) are in hours, as on screen, and the column heading says so.
### What the Excel workbook contains
* One sheet per chart, named after the chart. Excel allows 31 characters and no `\ / * ? : [ ]` in a sheet name, so long names are shortened, those characters are dropped, and a repeated name gets a number added.
* On each sheet, a header row, then one row per data point, with a column for each grouping and each value. A chart split two ways (by owner and by tier, say) comes out as one row per combination rather than a grid, which is the shape a pivot table wants.
* A KPI's sheet holds a label and a single value.
* Money cells are numbers in a currency format and cycle times are numbers of hours, so the sheet can still add them up.
The workbook has no title page. It does not record the dashboard's date range or when it was generated, so put the period in the file name.
### How each chart type comes out
The workbook carries the numbers behind every chart. The PDF, and the copy of the dashboard in a scheduled email, draw only some chart types.
| Chart type | PDF | Excel | Copy in the email |
| - | - | - | - |
| **KPI**, **Gauge** | The number, without a trend line or target | A label and the value | The number |
| **Table** | Every row, with the header repeated on each page. A table with two groupings becomes a grid: the first grouping down the side, a total column, then one column per value of the second | One row per combination | The first 8 rows, then a line counting the rest |
| **Bar Chart**, **Stacked Bar**, **Pie Chart** | Vertical bars. A pie is drawn as bars | One row per bar or segment | An image of the bars |
| **Horizontal Bar**, **Stacked Horizontal Bar** | Horizontal bars | One row per bar or segment | An image of the bars |
| **Line Chart** | A line | One row per point | An image of the line |
| **Scatter Plot** | A scatter plot | One row per point | An image of the plot |
| **Donut Chart**, **Area Chart**, **Sparkline**, **Treemap**, **Funnel**, **Waterfall**, **Radar**, **Heatmap**, **Timeline** | A one-line note, such as "Donut charts are not drawn in PDF exports yet. Open the dashboard to see this one." | The chart's data | "Open the dashboard to see this chart." |
Bar and line charts in the PDF and in the email cut category labels at 20 characters, so a long vendor name ends in an ellipsis. The workbook keeps it whole.
A chart whose data cannot be loaded keeps its heading and says "The data for this chart is not available." in all three. That is usually a Radar or Inspect chart, where the module is off for your organization or the person the export runs as cannot see it.
<Tip>
Several of the ready-made dashboards lean on donuts, heatmaps and treemaps. If a dashboard is headed for a PDF, open each of those charts with **Edit** and pick **Bar Chart** or **Horizontal Bar** under **Chart Type**, or **Table** under **Display**. The change applies for everyone who uses the dashboard. The alternative is to send the workbook alongside the PDF.
</Tip>
### Dates, filters and access
* **Date range.** An export uses the range saved in the dashboard's **Date Range** control. A relative range such as **Last 3 months** or **Month to date** is worked out when the file is generated, in your time zone. Only people who can edit the dashboard can change its range.
* **Charts with their own range.** A chart that carries its own date range (its card shows the range under its name) keeps it in the export, as it does on screen.
* **Filters saved on a chart.** Filters set in the chart editor apply.
* **Filters in the toolbar.** If your dashboard's toolbar has a **+** beside **Date Range** for adding filters, those filters are not saved with the dashboard. They change your screen only, and no export or scheduled email sees them. To filter an export, add the filter to each chart in the chart editor.
* **Access.** An export reads the same data as the dashboard. Radar and Inspect charts also need the person the export runs as to have access to those modules. A PDF or Excel export runs as you. A scheduled email runs as the dashboard's creator (see [Whose schedule it is](#whose-schedule-it-is)).
## Scheduling a dashboard by email
A schedule emails the dashboard to a list of addresses on the days you pick. Each email can carry the PDF, the workbook, a copy of the dashboard in the message body, or any mix of the three.
<Steps>
<Step title="Open the schedule">
On **Dashboards**, open the dashboard's actions menu and choose **Schedule export**. The **Scheduled Export** dialog opens.
</Step>
<Step title="Switch it on">
Tick **Enable scheduled export**. The rest of the form stays grayed out until you do.
</Step>
<Step title="Pick when it goes">
Under **Frequency**, choose **Daily**, **Weekly** or **Monthly**. For **Weekly**, pick one or more **Days of the week**. For **Monthly**, pick one or more **Days of the month**, from 1 to 28.
</Step>
<Step title="Pick what it carries">
Under **Attachments**, turn on **Attach PDF**, **Attach Excel**, or both. **Attach PDF** is on to start with. Tick **Include a copy of the dashboard in the email** to draw the charts into the message itself. You need at least one of the three.
</Step>
<Step title="Add the recipients">
In **Recipients**, type an address and press Enter, then type the next. An address shown in red is not valid and blocks saving. A schedule takes up to 50 addresses.
</Step>
<Step title="Write the email, if you want to">
**Subject**, **Email Title** and **Message** under **Email Copy** are optional. Left blank, each uses the default wording.
</Step>
<Step title="Send yourself a test">
Click **Send test to me**. See [Testing before you save](#testing-before-you-save).
</Step>
<Step title="Save">
Check the **Next export** line at the bottom of the form, then click **Save**.
</Step>
</Steps>
<Frame>
<img alt="The Scheduled Export dialog with Enable scheduled export ticked, Weekly on Monday, Attach PDF and Attach Excel on, the dashboard copy included, two recipients, a custom subject and message, and Next export: Monday, Sep 28" />
</Frame>
If something is missing when you click **Save** or **Send test to me**, a red line under the form names it: "Add at least one recipient email address.", "One or more recipient emails are invalid.", "Attach a file or include a copy of the dashboard in the email.", "Pick at least one day of the week." or "Pick at least one day of the month."
A dashboard has one schedule. To send it on two cadences, or to two audiences with different wording, you need a second dashboard, for example a second copy of the same template from **Browse templates**.
### When it sends
* Scheduled emails go out once a day at about 14:00 UTC: 10:00 in New York in summer and 9:00 in winter. You cannot choose the hour.
* Days are counted in US Eastern time, and a schedule has no time zone setting. At UTC+10 or further east, the email lands shortly after midnight on the following local day.
* The dashboard's date range is worked out in US Eastern time at the moment of sending, so **Last 7 days** means the seven days up to that send.
* **Next export** shows the date of the next send in your own time zone. Once today's send has gone out, it shows the next matching day.
* **Days of the month** runs from 1 to 28 so every chosen day exists in every month. There is no option for the last day of the month.
### Recipients
* Any address works. Recipients do not need a Coverbase account, and Coverbase does not check them against your members.
* Each recipient gets a message of their own, so nobody sees who else is on the list. A schedule takes up to 50 addresses. For a wider or changing audience, send to a mailing list that your email team maintains.
* The email has no unsubscribe link. It tells the reader that someone in your organization subscribed their address, so anyone who wants to stop receiving it has to ask you.
* The **Open dashboard** button in the email needs a Coverbase sign-in to your organization. Recipients without one can read the attachments and the copy in the email, not the live dashboard.
### The subject, title and message
| Field | Left blank | Limit |
| - | - | - |
| **Subject** | "Dashboard scheduled export:" followed by the dashboard's name | 300 characters |
| **Email Title** | The dashboard's name, as the heading of the message | 200 characters |
| **Message** | A line saying the export is attached or below, then the dashboard's description | 4,000 characters |
**Message** takes Markdown, so you can use bold, links and lists, but not tables. HTML is shown as typed rather than rendered. A message you write replaces both the default line and the dashboard's description.
Each field can carry these tokens, filled in on every send:
| Token | Becomes |
| - | - |
| `{{dashboard::name}}` | The dashboard's name |
| `{{dashboard::date}}` | The send date, as `YYYY-MM-DD` |
| `{{dashboard::url}}` | A link to the dashboard in Coverbase |
| `{{org::name}}` | Your organization's name |
A token with nothing to fill it is left blank rather than printed.
### Attachments and the copy in the email
* The attachments are the same files **Export as PDF** and **Export as Excel** produce. Each is named after the dashboard with the send date added, for example `Strategic_Sourcing_Overview_2026-09-28.pdf`. Spaces and most punctuation in the name become underscores.
* The copy in the email follows the [chart type table](#how-each-chart-type-comes-out): KPIs and tables as text, bars, lines and scatter plots as images, and a one-line pointer to the dashboard for the rest.
* The copy carries at most 12 chart images, and 3 MB of images in all. A chart past either limit becomes the one-line pointer.
* A table in the copy shows its first 8 rows. The attachments carry every row.
* The whole email, attachments included, has to stay under 10 MB, or it is not delivered. A large dashboard with both files attached can pass that. Drop one attachment, or split the dashboard.
### Testing before you save
**Send test to me** sends the dashboard, with the settings as they stand in the dialog, to your own address only. Recipients are left out, the subject starts with `[Test]`, and nothing needs saving first. The test goes out straight away rather than at the scheduled time, and the dialog confirms with "Test email on its way to you."
The button works once **Enable scheduled export** is ticked. It checks the form the same way **Save** does, so it needs at least one recipient in the list even though none of them receive the test.
## What recipients receive
Each send is one email from `noreply@coverbase.ai`, wrapped in the same layout as your team's notification emails (the **Internal (team)** layout, see [Choosing a layout](/user-guides/email-notifications#choosing-a-layout)). Replies go to that no-reply address, so put a contact in your **Message** if you want questions. From the top, the email holds:
1. The heading: your **Email Title**, or the dashboard's name.
2. Your **Message**. Without one, a line such as "Your scheduled export of Strategic Sourcing Overview from Coverbase is attached.", then the dashboard's description.
3. The copy of the dashboard, chart by chart, if you ticked **Include a copy of the dashboard in the email**.
4. A line naming the attached files.
5. An **Open dashboard** button.
6. A closing line: "You are receiving this email because someone in your organization subscribed this address to a recurring dashboard export."
## Changing, pausing and deleting a schedule
All three start from **Schedule export** on the dashboard's row.
* **Change it.** Edit anything and click **Save**. The next send uses the new settings.
* **Pause it.** Clear **Enable scheduled export** and click **Save**. Nothing sends, and every setting is kept for when you tick it again. A paused schedule can be unfinished: it saves without recipients, attachments or a day. Only an address that is not valid blocks saving it.
* **Delete it.** Click **Delete schedule**. It takes effect at once, with no confirmation, and the recipients and email copy go with it. The button appears only once a schedule has been saved.
Deleting the dashboard stops its schedule too, and a chart removed from the dashboard drops out of the next email.
The **Dashboards** list does not show which dashboards have a schedule. Open **Schedule export** on a dashboard to find out.
## Whose schedule it is
A schedule sends on behalf of the dashboard's creator, the person in the **Created by** column on **Dashboards**, whoever set the schedule up.
* **The creator's notification setting.** Everyone has a **Dashboard scheduled exports** switch in the **Export** group of their notification settings (**Account → Notifications**, see [Who receives what](/user-guides/email-notifications#who-receives-what)). Turning it off pauses the schedules on every dashboard that person created, for every recipient. It does not stop the email reaching someone who is only a recipient.
* **The warning.** While the switch is off, the creator sees "Dashboard scheduled exports are turned off in your notification settings, so this schedule will not send." at the top of the **Scheduled Export** dialog. Nobody else sees it, so if a schedule has gone quiet, ask the creator to check their setting.
* **Radar and Inspect charts** are drawn with the creator's access. If the creator cannot see those modules, those charts say "The data for this chart is not available." in every email.
<Frame>
<img alt="Account notification settings with the Export group expanded, showing Assessment report ready, Report ready for download, Dashboard scheduled exports and Documents ready for bulk download, each with an Email switch" />
</Frame>
## When someone leaves or loses access
Recipients are addresses, not accounts, so a change to someone's access changes nothing about a schedule.
* **A recipient leaves or loses their Coverbase account.** They keep receiving every send, attachments and the copy of the dashboard included, until someone removes their address from the schedule. The **Open dashboard** button stops working for them, but the data still arrives.
* **The dashboard's creator leaves.** The schedule keeps sending. Any Radar or Inspect charts on it switch to "The data for this chart is not available." because the send can no longer draw on the creator's access.
When someone leaves your team, check the schedules on the dashboards they received or created.
## Who can do what
| Task | Who |
| - | - |
| Export a dashboard to PDF, Excel or CSV, or download a chart image | People with the dashboard export permission, which Admins have |
| Create, change, pause or delete a schedule, or send a test | People who can both edit and export dashboards, which Admins can (see [What custom roles do not restrict](/user-guides/permissions-and-roles#what-custom-roles-do-not-restrict)) |
| Pause every schedule on the dashboards they created | The dashboard's creator, from their notification settings |
| Receive the email | Any email address |
Anyone else sees **Schedule export** grayed out, with "Your user role doesn't have permissions to do this." when they point at it. Any Admin can change or delete any dashboard's schedule, including one someone else set up.
## Limits
| What | Limit |
| - | - |
| Schedules per dashboard | One |
| Sends per day | One, at about 14:00 UTC |
| Days of the month | 1 to 28 |
| **Subject** | 300 characters |
| **Email Title** | 200 characters |
| **Message** | 4,000 characters |
| Chart images in the copy of the dashboard | 12, and 3 MB in all |
| Table rows in the copy of the dashboard | 8 |
| Recipients per schedule | 50 |
| One email, attachments included | 10 MB |
| Category labels on PDF bar and line charts | 20 characters |
| Excel sheet names | 31 characters |
## Troubleshooting
| Symptom | Cause | Fix |
| - | - | - |
| **Schedule export** is grayed out | Your role cannot edit dashboards | Ask an Admin to set up or change the schedule. |
| The dialog says the schedule will not send | You created the dashboard, and your **Dashboard scheduled exports** switch is off | Turn it back on under **Account → Notifications**, in the **Export** group. |
| A schedule has stopped sending | It was paused, the creator turned off **Dashboard scheduled exports**, the dashboard was deleted, or the email grew past 10 MB | Reopen **Schedule export** and check **Enable scheduled export**. Ask the creator to check their setting. On a large dashboard, drop an attachment. |
| The email arrives a day after the day you picked | You are at UTC+10 or further east, where the 14:00 UTC send lands after midnight | **Next export** shows the date in your time zone. Pick the previous day in the schedule to receive it on the day you want. |
| A chart in the PDF is a one-line note | Its chart type is not drawn in PDF (see [the chart type table](#how-each-chart-type-comes-out)) | Switch the chart to a bar chart or a table, or read its numbers in the workbook. |
| A chart says "The data for this chart is not available." | It reads Radar or Inspect, and the module is off or the person the export runs as cannot see it: you for a file, the creator for an email | Export as someone with access, or ask the dashboard's creator about their access. |
| The export ignores a filter you set | Filters added in the dashboard toolbar are not saved | Add the filter to each chart in the chart editor. |
| The figures cover a different period than you expected | The export uses the saved date range, worked out when it runs, and a chart with its own range keeps it | Check the **Date Range** control and each chart's own range before you export. |
| A former colleague still receives the email | Recipients are addresses, not accounts | Remove their address in **Schedule export** and save. |
| A recipient cannot open the dashboard from the email | **Open dashboard** needs a Coverbase sign-in to your organization | Rely on the attachments, or give them an account. |
| The export dialog shows "Encountered an error while generating the file" | The file failed to build | Close the dialog and try again. If it keeps failing, contact support. |
## Related
<CardGroup>
<Card title="Dashboards and the chart library" icon="chart-line" href="/user-guides/dashboard-library">
The ready-made dashboards and charts, and how to put them on a dashboard of your own.
</Card>
<Card title="Reporting overview" icon="file-lines" href="/reporting/overview">
Assessment deliverables: Word templates, PDF and spreadsheet exports, and the due-diligence file.
</Card>
<Card title="Email and notifications" icon="envelope" href="/user-guides/email-notifications">
The layout the scheduled email uses, and where your own notification settings live.
</Card>
<Card title="Permissions and roles" icon="lock-keyhole" href="/user-guides/permissions-and-roles">
Who can edit dashboards and their schedules.
</Card>
</CardGroup>
# Dashboards and the chart library
Source: https://docs.coverbase.com/user-guides/dashboard-library
The fifteen dashboards and 110 charts Coverbase ships ready to use: what each one shows, who it is built for, and how to put them on a dashboard of your own.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. Read it when you are building a dashboard for a board pack, a program review or a renewal negotiation and want to know what is already available before you build a chart from scratch.
</Info>
A dashboard in Coverbase is a grid of charts drawn from live workspace data across vendors, assessments, findings, contracts and intake requests. You can build one chart at a time, but most reporting questions have already been answered: the library ships **15 ready-made dashboards** and **110 individual charts**, each written for a specific job rather than for a table in the database.
Open them from **Dashboards**: **Browse templates** starts a whole dashboard, and **Chart library** on any open dashboard adds individual charts to it. Clicking a dashboard card creates that dashboard straight away, under the template's name, and opens it.
<Note>
Applying a template makes a copy you own. The charts and the dashboard become ordinary records in your workspace, editable like any other. Retitle them, change the measure, re-slice them, resize them, delete them. Nothing syncs back: later changes to the Coverbase template never reach your copy, and your edits never leave your workspace.
</Note>
## The ready-made dashboards
Each one is a laid-out set of charts from the library, sized for a 12-column grid and ordered so the headline numbers sit at the top.
| Dashboard | Built for | Charts | Needs |
| - | - | -: | - |
| **Executive TPRM Overview** | Executives and the board | 8 | none |
| **Vendor Risk Portfolio** | Risk analysts and the TPRM lead | 9 | none |
| **Assessment Operations** | Assessment team leads | 9 | none |
| **Cycle Time & SLA** | Program managers tracking SLAs | 10 | none |
| **Contract Spend & Renewals** | Procurement and vendor managers | 13 | Contracts |
| **Savings & Value Capture** | Procurement leadership and finance | 8 | Contracts |
| **Third-Party Exposure** | Risk and finance leaders | 8 | Contracts |
| **Intake & Demand** | Intake owners and program managers | 7 | Intake |
| **Control Assurance** | Control owners and compliance | 9 | none |
| **Tag & Ownership Coverage** | TPRM program owners | 9 | none |
| **Monthly Executive Report** | Executives and the board | 9 | none |
| **Findings and Remediation** | The TPRM lead and risk analysts | 10 | none |
| **Supplier Tier Review** | The TPRM lead and the risk committee | 7 | none |
| **Relationship Owner Accountability** | Business relationship owners and their leadership | 4 | none |
| **Radar Signal Triage** | Analysts triaging Radar signals and the TPRM lead | 10 | Radar |
<Frame>
<img alt="The Coverbase dashboard template gallery, showing template cards with layout thumbnails, audiences and job labels" />
</Frame>
<Tip>
Start from the dashboard closest to your question and delete what you do not need. That is faster than assembling one chart at a time, and the layout already reads top-down: headline tiles, then the breakdowns, then the detail.
</Tip>
## Every dashboard in detail
### Executive TPRM Overview
The one-screen answer to how third-party risk is trending: portfolio size, risk mix, assessment throughput and where the gaps are.
<Frame>
<img alt="Executive TPRM Overview dashboard in Coverbase" />
</Frame>
**On it:** Total Vendors, Active Vendors, Assessments Run, Median Assessment Cycle Time, Vendors by Inherent Risk Level, Assessments Over Time, Vendor Status by Inherent Risk, Issues by Control Set.
**Reach for it when:** board and executive reporting; quarterly business review; monthly program review.
### Vendor Risk Portfolio
The portfolio in depth: risk tiering, domain exposure, growth and how the book is split across analysts.
<Frame>
<img alt="Vendor Risk Portfolio dashboard in Coverbase" />
</Frame>
**On it:** Total Vendors, Active Vendors, Vendors Onboarding, Issues Raised, Vendors by Inherent Risk Level, Vendors Added by Quarter and Risk, Risk Domain Exposure, Portfolio by Risk Analyst, Risk Register.
**Reach for it when:** portfolio review; risk committee pack; audit and regulator evidence.
### Assessment Operations
Run the assessment queue: volume, outcomes, who is loaded and whether high-risk vendors are getting the scrutiny they should.
<Frame>
<img alt="Assessment Operations dashboard in Coverbase" />
</Frame>
**On it:** Assessments Run, Median Assessment Cycle Time, 95th Percentile Cycle Time, Issues Raised, Assessments Over Time, Assessment Outcomes, Assessment Workload by Assignee, Outcome by Inherent Risk, Assessment Coverage by Quarter.
**Reach for it when:** weekly team stand-up; queue management; capacity and headcount planning.
### Cycle Time & SLA
Where the time goes. Median and tail cycle times, the phase-by-phase breakdown, and the outliers that break an SLA.
<Frame>
<img alt="Cycle Time & SLA dashboard in Coverbase" />
</Frame>
**On it:** Median Assessment Cycle Time, Average Assessment Cycle Time, 95th Percentile Cycle Time, Assessments Run, Cycle Time Trend, Cycle Time by Inherent Risk, Time Spent Collecting Documents, Time Spent in Review, Cycle Time by Assignee, Cycle Time Distribution.
**Reach for it when:** SLA reporting; process improvement; bottleneck analysis.
### Contract Spend & Renewals
Committed spend, where it is concentrated, and the renewal runway: the view to take into a negotiation.
<Frame>
<img alt="Contract Spend & Renewals dashboard in Coverbase" />
</Frame>
**On it:** Total Contract Value, Contracts Under Management, Average Contract Value, Negotiated Savings, Spend by Department, Spend Concentration by Vendor, Renewal Calendar, Value Up for Renewal by Quarter, Contracts by Status, New Contract Value by Quarter, Spend by Supplier Tier, Spend by Relationship Owner, Contract Value by Owner and Tier.
**Reach for it when:** renewal negotiation prep; budget planning; vendor rationalisation.
### Savings & Value Capture
What the program saved, where it came from, and how much of it landed rather than staying on paper.
<Frame>
<img alt="Savings & Value Capture dashboard in Coverbase" />
</Frame>
**On it:** Negotiated Savings, Realized Savings, Consolidation Savings, Negotiated Savings by Department, Realized Savings by Department, Savings Captured by Quarter, Savings by Vendor Tag, Savings Contribution Waterfall.
**Reach for it when:** procurement performance reporting; finance reconciliation; board and executive reporting.
### Third-Party Exposure
Risk and money on one screen: how much spend sits with high-risk vendors, and which of them carry the open control gaps.
<Frame>
<img alt="Third-Party Exposure dashboard in Coverbase" />
</Frame>
**On it:** Total Contract Value, Total Vendors, Issues Raised, Spend by Inherent Risk Tier, Vendors by Inherent Risk Level, Spend Concentration by Vendor, Issues by Vendor Risk Tier, Renewals by Risk Tier.
**Reach for it when:** risk committee pack; concentration-risk reporting; board and executive reporting.
### Intake & Demand
The front of the funnel: what the business is asking for, where requests stall, and the assessment load coming next.
<Frame>
<img alt="Intake & Demand dashboard in Coverbase" />
</Frame>
**On it:** Intake Requests, Total Vendors, Assessments Run, Intake Funnel, Intake Volume Over Time, Intake Outcomes by Month, Vendors Added Over Time.
**Reach for it when:** demand forecasting; capacity and headcount planning; intake process improvement.
### Control Assurance
Which controls and frameworks vendors fail, how that is trending, and the vendors carrying the most gaps.
<Frame>
<img alt="Control Assurance dashboard in Coverbase" />
</Frame>
**On it:** Issues Raised, Assessments Run, Total Vendors, Issues Over Time, Issues by Control Weight, Issues by Control Set, Most Failed Controls, Control Set Failures by Risk Tier, Issues by Vendor.
**Reach for it when:** framework gap analysis; audit and regulator evidence; remediation planning.
### Tag & Ownership Coverage
Data-quality and accountability: what is classified, what is owned, and which segments are quietly going unassessed.
<Frame>
<img alt="Tag & Ownership Coverage dashboard in Coverbase" />
</Frame>
**On it:** Total Vendors, Active Vendors, Assessments Run, Vendors by Tag Category, Ownership Coverage, Tag Category by Risk Tier, Portfolio by Tag, Vendor Status by Analyst, Assessment Coverage by Tag.
**Reach for it when:** data-quality review; analyst load balancing; coverage assurance.
### Monthly Executive Report
Built to be [exported](/user-guides/dashboard-exports) into a monthly pack: portfolio size and tier mix, findings raised against findings resolved, assessment effort by tier, and where the remediation sits.
<Frame>
<img alt="Monthly Executive Report dashboard in Coverbase" />
</Frame>
**On it:** Total Vendors, Assessments Run, Findings Raised, Findings Resolved, Findings Raised vs Resolved, Portfolio by Supplier Tier, Assessments by Supplier Tier, Findings by Supplier Tier, Findings by Severity.
**Reach for it when:** board and executive reporting; monthly program review; quarterly business review.
### Findings and Remediation
The remediation book end to end: what is open, what closed, how severe it is, where it came from and who owes the work.
<Frame>
<img alt="Findings and Remediation dashboard in Coverbase" />
</Frame>
**On it:** Findings Raised, Findings Resolved, Issues Raised, Total Vendors, Findings Raised vs Resolved, Findings by Stage, Findings by Severity, Findings by Source, Resolutions by Month, Remediation Load by Relationship Owner.
**Reach for it when:** remediation stand-up; monthly program review; showing that remediation is working.
### Supplier Tier Review
Everything sliced by supplier tier, for a program that has to show its effort and its exposure follow criticality.
<Frame>
<img alt="Supplier Tier Review dashboard in Coverbase" />
</Frame>
**On it:** Portfolio by Supplier Tier, Supplier Tier by Inherent Risk, Assessments by Supplier Tier, Assessments by Tier Over Time, Findings by Supplier Tier, Severity by Supplier Tier, Assessment Outcomes by Tier.
**Reach for it when:** tier-based reporting; risk committee pack; tiering review.
### Relationship Owner Accountability
The business owner's view: how many suppliers each owner is accountable for, the assessments run on them, and the remediation they owe.
<Frame>
<img alt="Relationship Owner Accountability dashboard in Coverbase" />
</Frame>
**On it:** Book of Business by Relationship Owner, Remediation Load by Relationship Owner, Assessments by Relationship Owner, Suppliers by Owner and Tier.
**Reach for it when:** accountability reporting; capacity planning; renewal preparation.
### Radar Signal Triage
What Radar raised about your vendors, where each signal stands, and which detectors and vendors keep the queue full. It opens on the last three months.
<Frame>
<img alt="Radar Signal Triage dashboard in Coverbase" />
</Frame>
**On it:** Radar Signals, Radar Signals In Alert, Triaged Radar Signals, Dismissed Radar Signals, Radar Signals by Status, Radar Signals by Severity, Radar Signals by Month and Status, Radar Signals by Detector, Radar Signals In Alert by Vendor, Radar Signals by Supplier Tier and Severity.
**Reach for it when:** weekly triage review; continuous monitoring reporting; tuning monitoring.
The totals count each signal once, however many detectors flagged it. The per-detector, per-source, per-vendor and per-tier charts count a signal under each detector, source, vendor or tier it touches, so they can add up to more than the total.
## The chart library
The dashboards above draw on 93 of the library's charts. Every one of them is also available on its own, along with 17 more that no packaged dashboard uses. Open **Chart library** from a dashboard, search or pick a shelf, select as many as you want, and they are added below whatever is already on the grid, so an add never lands on top of a widget you positioned.
Charts are filed by the question they answer, not by the table the data comes from, so a spend chart and a vendor chart can sit on the same shelf if they answer the same question.
<Frame>
<img alt="The Coverbase chart library dialog, showing the search field, category shelves with counts, chart cards, and a live preview of the selected chart" />
</Frame>
Selecting a card renders it against your own data in the panel beside the grid, so you can see a real result before you commit it to the dashboard. The preview covers all time; once the chart is added, the dashboard's own date range applies. You can select several and add them in one go.
<Frame>
<img alt="Four chart cards from the Coverbase chart library, each with a preview thumbnail, description and job labels" />
</Frame>
Search matches names, descriptions and the job labels on each card, so **renewals**, **board reporting** and **SLA** all find something. It also matches the vocabulary your workspace uses: if you have renamed "vendor" to "supplier", searching for suppliers finds the vendor charts.
### What is on each shelf
| Shelf | Charts | Answers |
| - | -: | - |
| **Risk posture** | 18 | How big the portfolio is, how risky, and where the risk sits |
| **Throughput & outcomes** | 12 | How much work the program completes and how it resolves |
| **Cycle time & SLA** | 11 | How long things take, including the tail that breaches an SLA |
| **Workload & ownership** | 14 | Who is carrying the queue, who owns the relationship, and how consistently they decide |
| **Spend & renewals** | 16 | What is committed, where it concentrates, and what renews when |
| **Savings & value** | 9 | What was negotiated, what landed, and who banked it |
| **Control assurance** | 20 | Which controls fail and where, and whether the findings raised are closing |
| **Intake & demand** | 7 | Where new vendor requests come from and where they stall |
| **Coverage & data quality** | 3 | Whether the taxonomy is applied well enough to trust the rest |
<AccordionGroup>
<Accordion title="Risk posture · 18 charts" icon="shield-check">
| Chart | Type | What it shows |
| - | - | - |
| **Total Vendors** | KPI tile | Every vendor on record, with the month-by-month trend beneath it. |
| **Active Vendors** | KPI tile | Vendors currently in an active relationship, excluding onboarding and retired ones. |
| **Vendors by Inherent Risk Level** | Donut | The shape of the portfolio: how much of it sits in each inherent risk tier. |
| **Vendors by Residual Risk Level** *(residual risk)* | Donut | Where the portfolio lands after controls are credited. |
| **Vendor Status by Inherent Risk** | Heatmap | Which lifecycle stages hold the risky vendors: the cells to work down first. |
| **Vendors Added by Quarter and Risk** | Stacked column | Whether the vendors joining the portfolio are getting riskier over time. |
| **Risk Domain Exposure** | Heatmap | Vendor counts across every risk domain and level: where domain risk clusters. |
| **Risk Domain Profile** | Radar | The portfolio's shape across risk domains, side by side on one radar. |
| **Risk Register** | Table | Vendor counts by analyst and inherent risk as a table you can export. |
| **Portfolio by Supplier Tier** | Donut | How the portfolio splits across supplier tiers: the criticality view. |
| **Supplier Tier by Inherent Risk** | Heatmap | Tier against inherent risk. A Tier 1 supplier scored low risk, or a Tier 4 one scored high, is a tiering question rather than a risk one. |
| **Risks by Domain and Appetite** *(Risk register)* | Stacked bar | Live register risks per domain, split by whether their residual sits inside or outside the domain's appetite. |
| **Spend by Inherent Risk Tier** *(Contracts)* | Bar | How much money is committed to the riskiest vendors: the exposure number. |
| **Severity by Supplier Tier** | Heatmap | Finding severity against supplier tier, so a cell that should be empty stands out when it is not. |
| **Radar Signals** *(Radar)* | KPI tile | Every signal Radar raised about your vendors, trended by week. |
| **Radar Signals by Severity** *(Radar)* | Donut | The severity mix of what Radar raised. |
| **Radar Signals by Supplier Tier and Severity** *(Radar)* | Stacked column | Where on the tiering Radar is finding trouble, and how serious it is. |
| **Tag Category by Risk Tier** | Heatmap | Which segments of the portfolio carry the risk, cell by cell. |
</Accordion>
<Accordion title="Throughput & outcomes · 12 charts" icon="gauge-high">
| Chart | Type | What it shows |
| - | - | - |
| **Vendor Lifecycle Funnel** | Funnel | How vendors distribute across lifecycle statuses, largest stage first. |
| **Assessments Run** | KPI tile | Total assessments in the period, trended by month. |
| **Assessments Over Time** | Line | Assessment volume week by week. |
| **Assessment Outcomes** | Donut | How assessments resolve: approvals, conditional approvals and rejections. |
| **Assessments by Supplier Tier** | Column | Whether assessment effort goes where the criticality is. |
| **Assessments by Tier Over Time** | Stacked column | Assessment volume per month, split by supplier tier. |
| **Assessment Outcomes by Tier** | Table | Whether the tiers that matter are the ones passing, as a grid you can export. |
| **Triaged Radar Signals** *(Radar)* | KPI tile | Signals someone acted on: a finding, a case, a reassessment or an acknowledgement. |
| **Dismissed Radar Signals** *(Radar)* | KPI tile | Signals dismissed as not relevant to your vendors. |
| **Radar Signals by Month and Status** *(Radar)* | Stacked column | Each month's signals, split by where they stand now, so a month still alerting stands out. |
| **Radar Signals by Detector** *(Radar)* | Table | Which detectors raise the signals, and how many of each are still alerting. |
| **Radar Signals by Source** *(Radar)* | Table | Which sources feed the signals, and how many are still alerting. |
</Accordion>
<Accordion title="Cycle time & SLA · 11 charts" icon="stopwatch">
| Chart | Type | What it shows |
| - | - | - |
| **Median Assessment Cycle Time** | KPI tile | The typical end-to-end time from document collection to a completed assessment. |
| **95th Percentile Cycle Time** | KPI tile | The tail: how long the slowest assessments take, which is what breaches an SLA. |
| **Average Assessment Cycle Time** | KPI tile | Mean end-to-end duration, for reporting alongside the median. |
| **Cycle Time Trend** | Line | Median cycle time month by month, showing whether the program is speeding up or slowing down. |
| **Cycle Time by Inherent Risk** | Column | Whether higher-risk reviews take longer, or only feel like it. |
| **Cycle Time by Assignee** | Bar | Median time to close per reviewer: where coaching or rebalancing would pay off. |
| **Time Spent Collecting Documents** | Line | Median time from request to indexed evidence, usually the biggest single delay. |
| **Time Spent in Review** | Bar | Median time from evidence review to completion, by reviewer. |
| **Time Spent Analysing Controls** | Line | Median time the control evaluation phase takes, month by month. |
| **Cycle Time Distribution** | Scatter | Every assessment as its own point, so outliers stay visible instead of averaging away. |
| **Cycle Time by Vendor Tag** | Bar | Which vendor segments are slow to get through review. |
</Accordion>
<Accordion title="Workload & ownership · 14 charts" icon="users">
| Chart | Type | What it shows |
| - | - | - |
| **Portfolio by Risk Analyst** | Stacked bar | Each analyst's book of vendors, split by inherent risk: a load-balancing view. |
| **Book of Business by Relationship Owner** | Bar | How many suppliers each business owner is accountable for. |
| **Suppliers by Owner and Tier** | Table | An exportable grid of supplier counts per relationship owner and tier. |
| **Assessment Workload by Assignee** | Bar | Who is carrying the queue right now, and how evenly it is spread. |
| **Outcomes by Assignee** | Stacked bar | Each reviewer's decision mix: an early read on inconsistent standards. |
| **Most Assessed Vendors** | Bar | The vendors absorbing the most review effort. |
| **Assessments by Analyst and Risk** | Table | An exportable grid of assessment counts per analyst and risk tier. |
| **Assessments by Relationship Owner** | Bar | Assessment volume by the business owner of the supplier, rather than by who ran the review. |
| **Remediation Load by Relationship Owner** | Stacked bar | Which business owner's suppliers carry the findings, split by status group: the open band is the load, the closed one the history. |
| **Radar Signals In Alert** *(Radar)* | KPI tile | Signals still in alert: the triage queue. |
| **Radar Signals by Status** *(Radar)* | Donut | Where every signal stands: alerting, triaged, dismissed or closed. |
| **Radar Signals In Alert by Vendor** *(Radar)* | Bar | The vendors with the most signals waiting in the triage queue. |
| **Ownership Coverage** | Bar | Vendors per risk analyst, including the ones nobody owns yet. |
| **Vendor Status by Analyst** | Stacked bar | Each analyst's book by lifecycle stage: who is holding stalled onboarding. |
</Accordion>
<Accordion title="Spend & renewals · 16 charts" icon="calendar-days">
| Chart | Type | What it shows |
| - | - | - |
| **Total Contract Value** *(Contracts)* | KPI tile | Committed spend across every active contract, trended by month. |
| **Contracts Under Management** *(Contracts)* | KPI tile | How many contracts the program is tracking. |
| **Average Contract Value** *(Contracts)* | KPI tile | Mean contract size: the baseline for spotting outlier deals. |
| **Spend by Department** *(Contracts)* | Bar | Where the money is committed across the business. |
| **Spend Concentration by Vendor** *(Contracts)* | Treemap | How much of total spend sits with a handful of vendors. |
| **Spend by Vendor Tag** *(Contracts)* | Bar | Spend rolled up by the segments the org manages by. |
| **Renewal Calendar** *(Contracts)* | Column | Contracts expiring each quarter: the negotiation runway. |
| **Value Up for Renewal by Quarter** *(Contracts)* | Column | How much spend comes up for renegotiation each quarter. |
| **Renewals by Risk Tier** *(Contracts)* | Stacked column | Which risk tiers the upcoming renewals sit in, so reviews can be booked early. |
| **Contracts by Status** *(Contracts)* | Donut | Active versus expired contracts still on the books. |
| **New Contract Value by Quarter** *(Contracts)* | Area | Spend newly committed each quarter, by contract effective date. |
| **Average Contract Size by Department** *(Contracts)* | Column | Which departments sign large deals and which sign many small ones. |
| **Spend by Department and Risk** *(Contracts)* | Table | An exportable grid of committed spend per department and risk tier. |
| **Spend by Supplier Tier** *(Contracts)* | Bar | Committed spend against supplier tier, including spend that sits outside the tiers the program scrutinizes. |
| **Spend by Relationship Owner** *(Contracts)* | Bar | Which business owner's suppliers the money is committed to. |
| **Contract Value by Owner and Tier** *(Contracts)* | Table | Committed contract value per relationship owner and tier, across the whole book rather than a renewal window. |
</Accordion>
<Accordion title="Savings & value · 9 charts" icon="hand-holding-dollar">
| Chart | Type | What it shows |
| - | - | - |
| **Negotiated Savings** *(Contracts)* | KPI tile | Total savings negotiated off list or prior pricing. |
| **Realized Savings** *(Contracts)* | KPI tile | Savings that have landed, as opposed to those only negotiated. |
| **Consolidation Savings** *(Contracts)* | KPI tile | Savings from retiring overlapping vendors and consolidating spend. |
| **Negotiated Savings by Department** *(Contracts)* | Bar | Which parts of the business the savings came from. |
| **Realized Savings by Department** *(Contracts)* | Bar | Where negotiated savings converted into lower spend. |
| **Savings Contribution Waterfall** *(Contracts)* | Waterfall | How each department stacks up to the total savings number. |
| **Savings Captured by Quarter** *(Contracts)* | Area | Savings by contract effective date: the quarter-on-quarter run rate. |
| **Savings by Vendor** *(Contracts)* | Treemap | The suppliers where negotiation has moved the most money. |
| **Savings by Vendor Tag** *(Contracts)* | Bar | Which vendor segments the savings program is working. |
</Accordion>
<Accordion title="Control assurance · 20 charts" icon="triangle-exclamation">
| Chart | Type | What it shows |
| - | - | - |
| **Outcome by Inherent Risk** | Stacked column | Whether high-risk vendors are being held to a higher bar. |
| **Assessment Coverage by Quarter** | Stacked column | Assessments completed each quarter, split by the risk tier they covered. |
| **Issues Raised** | KPI tile | Control evaluations that came back as an issue, trended by month. |
| **Issues Over Time** | Line | Whether control gaps are trending up or down across the portfolio. |
| **Issues by Control Set** | Bar | Which frameworks vendors fail most often. |
| **Most Failed Controls** | Bar | The individual controls generating the most issues: the systemic gaps. |
| **Issues by Control Weight** | Donut | How many failures land on the controls the org weights most heavily. |
| **Issues by Vendor Risk Tier** | Stacked column | Whether issues concentrate in the vendors that can hurt most. |
| **Issues by Vendor** | Treemap | The vendors carrying the most open control gaps. |
| **Control Set Failures by Risk Tier** | Heatmap | Framework against risk tier, so the worst cells stand out. |
| **Inspect Issues by Application** *(Inspect)* | Table | Issues Inspect flagged in each application, beside the findings raised from them. |
| **Findings Raised** | KPI tile | Every finding on record, with the month-by-month trend beneath it. |
| **Findings Resolved** | KPI tile | Findings whose current status sits in a completed group, trended by month. |
| **Findings Raised vs Resolved** | Line | Whether findings close faster than they open. A finding counts in the month it first closed, so a past month never changes. |
| **Resolutions by Month** | Column | Findings closed each month, on the month they closed. A reopen does not erase the month it closed in. |
| **Findings by Stage** | Donut | Where the book sits: not started, in progress, or completed. |
| **Findings by Severity** | Column | The severity mix of the findings, so the worst of it is visible at a glance. |
| **Findings by Supplier Tier** | Stacked column | Whether findings concentrate in the tiers that matter. |
| **Findings by Source** | Donut | Where findings come from, such as a control evaluation, a monitoring alert or manual entry. |
| **Assessment Coverage by Tag** | Stacked column | Whether every tagged segment is getting assessed. |
</Accordion>
<Accordion title="Intake & demand · 7 charts" icon="inbox">
| Chart | Type | What it shows |
| - | - | - |
| **Vendors Onboarding** | KPI tile | How much of the portfolio is mid-onboarding right now. |
| **Vendors Added Over Time** | Area | Monthly intake into the portfolio: the demand the program has to absorb. |
| **Assessments by Initiator** | Column | Which teams and people are pulling the program's workload in. |
| **Intake Requests** *(Intake)* | KPI tile | New vendor requests submitted, trended by month. |
| **Intake Funnel** *(Intake)* | Funnel | Where requests sit between submission and acceptance, and where they pile up. |
| **Intake Volume Over Time** *(Intake)* | Area | Weekly request volume: the demand signal ahead of assessment load. |
| **Intake Outcomes by Month** *(Intake)* | Stacked column | How each month's requests resolved, so approval rates stay visible. |
</Accordion>
<Accordion title="Coverage & data quality · 3 charts" icon="tags">
| Chart | Type | What it shows |
| - | - | - |
| **Vendors by Tag Category** | Column | How much of the portfolio is classified under each tag category. |
| **Portfolio by Tag** | Treemap | The full tag map of the portfolio, sized by vendor count. |
| **Vendors by Tag Value** | Bar | The most common tag values, wherever the taxonomy is used. |
</Accordion>
</AccordionGroup>
## What you will and will not see
The library hides templates your workspace cannot fill, so you never add a chart that can only ever render empty.
| These charts need | Which means | If it is off |
| - | - | - |
| **Contracts** | The Contracts module enabled, and permission to read contracts | The 26 spend and savings charts are hidden, along with Contract Spend & Renewals, Savings & Value Capture and Third-Party Exposure |
| **Intake** | Permission to read intake requests | The 4 intake charts are hidden, along with Intake & Demand |
| **Radar** | The Radar module enabled, and permission to read Radar alerts or detectors | The 11 Radar signal charts are hidden, along with Radar Signal Triage |
| **Inspect** | The Inspect module enabled, and permission to read integrations | Inspect Issues by Application is hidden |
| **Risk register** | The Risk module enabled, and permission to read risks | Risks by Domain and Appetite is hidden |
| **Residual risk** | Residual risk scoring turned on for the workspace | Vendors by Residual Risk Level is hidden |
A dashboard inherits its charts' requirements: if any chart on it needs Contracts, the whole dashboard is hidden from workspaces without Contracts rather than arriving with holes in it. A shelf with nothing left to show drops out of the row of shelves.
The remaining 66 charts and 10 dashboards depend on nothing beyond vendors, assessments and findings, so every workspace sees them.
## Making them yours
A template is a starting point, not a fixed report. Once a chart is on your dashboard:
* **Retitle it.** The shipped names are descriptive, not fixed. "Median Assessment Cycle Time" may be "Time to clear a vendor" in your program.
* **Change the slice.** Most charts group by one dimension and split by another. Swapping either (tag, department, analyst, risk tier, quarter) usually gets you a different question answered by the same chart.
* **Resize and rearrange.** Drag any widget; the grid reflows around it.
* **Set the date range** on the dashboard rather than per chart. Every chart on it follows.
* **Mix shelves freely.** Nothing stops a savings chart sitting next to a cycle-time chart if that is the story your review needs.
<Warning>
Charts count across your whole organization, not only the records you can open, so everyone who opens a dashboard sees the same totals. Radar and Inspect charts are the exception: they show only to people who can see those modules. Money charts add up amounts in your base currency (US dollars unless your organization has set another). An amount in another currency counts only once a conversion rate is set for it; without one it is left out of the total rather than added as if it were dollars.
</Warning>
## Where to go next
<CardGroup>
<Card title="Contracts workspace" icon="file-signature" href="/user-guides/contracts-workspace">
The contract records behind every spend, renewal and savings chart in the library.
</Card>
<Card title="Requesting a vendor" icon="cart-plus" href="/user-guides/requesting-a-vendor">
The intake flow the Intake & Demand dashboard measures.
</Card>
<Card title="Permissions and roles" icon="user-shield" href="/user-guides/permissions-and-roles">
Why two people can open the same dashboard and see different numbers.
</Card>
<Card title="Reporting overview" icon="file-lines" href="/reporting/overview">
Assessment deliverables (Word templates, PDF and spreadsheet exports), as opposed to live dashboards.
</Card>
<Card title="Exporting and scheduling dashboards" icon="file-export" href="/user-guides/dashboard-exports">
Export a dashboard to PDF or Excel, or email it on a schedule.
</Card>
</CardGroup>
# Configuring your data model
Source: https://docs.coverbase.com/user-guides/data-model-configuration
What an admin can change in Coverbase without a professional-services engagement: custom fields on nine object types, statuses, approval options, risk scales, risk domains, tags, terminology, relationships, control sets, and automations.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is the reference for what your admins can change themselves. For the order to do it in on a new environment, see [Admin and setup](/user-guides/admin-setup).
</Info>
Coverbase is configured by your team, in the product, under **Configuration** in the left navigation. Everything on this page is a screen an admin opens rather than a ticket they file. Coverbase sits with you during onboarding, and connecting a system of record such as SAP, ProcessUnity or ServiceNow is integration work. The data model itself is yours to change whenever you want.
## Custom fields
Add fields of your own to capture what your program tracks and Coverbase does not ship as standard: an internal tier, a regulatory scope flag, a risk-exception owner, a business-line code, a review date.
<CardGroup>
<Card title="Nine object types" icon="cube">
Fields can be defined on **vendors, services, assessments, controls, evaluations, contracts, findings, reviews and engagements**. Each object holds one value per field definition.
</Card>
<Card title="Seven value types" icon="shapes">
Text, number, date, yes/no, single select, multi select, and user reference. Select fields carry the option list you define.
</Card>
<Card title="Grouped into sections" icon="layer-group">
Fields are organized into named, ordered sections, and a section is applied to the object types it belongs on, so a vendor form and a contract form show different things.
</Card>
<Card title="Filterable and reportable" icon="filter">
A custom field is a first-class field. It appears in the **Add filter** menu, in saved views, in sorting, in workflow conditions, and in the query and export APIs, under the same path everywhere. See the [field reference](/fields/overview).
</Card>
</CardGroup>
Custom field values can be populated by hand, by import, over the [Custom Fields API](/api-reference/custom-fields), or automatically by [Document Insights](/products/document-insights), which extracts a value from a document and carries a page citation back to the source. Automated writers never overwrite a value a person typed.
<Tip>
If your committee pack has a column, make it a custom field rather than a convention people follow in a notes box. A custom field can be filtered, sorted and exported; a note cannot.
</Tip>
## Record types and lifecycle states
Coverbase's own objects are the record types, and their vocabulary is configurable.
| What you configure | Where | Applies to |
| - | - | - |
| **Statuses** | Configuration → Statuses | Vendors, services, assessments, procurements, engagements, reviews, findings, contracts, RFPs, and Radar signals. Each status carries a name, a color, a description, and a group (`unstarted`, `started`, `completed`, `canceled`) so reporting knows what an in-flight record is without hard-coding your labels. |
| **Approval options** | Configuration → Assessment settings → Approval options | The outcome vocabulary on every gate. See [Reviews, approvals and gates](/user-guides/reviews-and-approvals). |
| **Risk scales** | Configuration → Scoring | The levels your evaluations, findings and vendor tiers are scored on, with your own labels, ordering and colors. |
| **Risk domains** | Configuration → Risk domains | The domains an assessment is split into, with standing reviewers per domain. |
| **Tags** | Configuration → Tags | Free-form labels for cross-cutting grouping, filterable everywhere. |
| **Terminology** | Configuration → Terminology | Rename core domain terms. If your organization says "supplier" and "issue" rather than "vendor" and "finding", the product says it too, everywhere, with no deploy. |
## Relationships
The relationship graph is part of the model, not a flat list of vendors.
* **Vendor → service → engagement → contract.** A vendor can hold many services, each with its own risk profile, owners, and assessments; engagements bind a service to a business use; contracts hang off the relationship and resolve into components.
* **Legal entities.** A vendor is matched to real corporate entities from registries, so the paper, the payments and the screening all attach to the entity that signs.
* **Nth-party relationships.** A vendor's own suppliers are recorded as relationships, so concentration and fourth-party exposure are queryable rather than anecdotal.
* **Documents, findings, obligations and reviews** attach to whichever level they belong to and roll up.
* **Your own references.** External IDs are carried on records so a Coverbase vendor and its row in your ERP, CMDB or GRC platform stay joined.
## Assessment content
<CardGroup>
<Card title="Control sets" icon="shield-check" href="/control-library">
Fork a template from the **Vendor Controls Library** or the **Internal Controls Library** (every one is listed in the Control Set library), or author your own from scratch. Your copy is fully editable: add controls, re-section, change weights, attach evidence sources.
</Card>
<Card title="Questionnaires" icon="clipboard-question" href="/user-guides/irq-library">
Build the inherent-risk questionnaire and any vendor-facing questionnaire, including branching, scoring, and per-section reviewers.
</Card>
<Card title="Clause sets" icon="file-contract" href="/user-guides/clause-set-library">
Your contract playbook: reference clauses with tiered fallback language, authored by hand, forked from the library, or extracted from your own template paper.
</Card>
<Card title="Report templates" icon="file-word" href="/reporting/assessment-report-templates">
Upload your own Word deliverable with placeholders and Coverbase fills it per assessment.
</Card>
</CardGroup>
## Automations
The **Workflows** section of the dashboard is a no-code designer. You compose a trigger, any number of conditions, and the actions that follow, then activate it. Workflows are versioned, each run is inspectable step by step, and the same definitions are readable and writable over the API.
Nothing about the orchestration layer is locked after go-live. A workflow can be edited, disabled, cloned or replaced by an admin at any time, and a running instance can be interrupted or redirected. See [Workflow engine](/integrations/workflow-engine).
## What still involves Coverbase
Where the line sits between self-serve and Coverbase-assisted work, for when you are planning a program:
| Self-serve | Involves Coverbase |
| - | - |
| Everything on this page | Some modules are released behind a per-organization feature flag, among them the workflow designer, custom roles and Inspect. Your account team switches them on for your organization; there is no build work and no professional-services engagement, and once a module is on, its configuration is entirely yours. |
| Connecting DocuSign, Slack, Jira and other API-key integrations from **Configuration → External integrations** | Deep bidirectional connectors to a GRC or ERP system of record, where field mapping to your instance is real integration work. See the [platform-specific guides](/integrations/guides/processunity). |
| Building, editing and replacing your own workflows | Nothing. Workflows built with you during onboarding are handed over as ordinary editable definitions, not as locked configuration. |
## Related
<CardGroup>
<Card title="Admin and setup" icon="rocket" href="/user-guides/admin-setup">
The setup sequence, in order, for a new environment.
</Card>
<Card title="Field reference" icon="table-list" href="/fields/overview">
Every field, its path, and where it can be used.
</Card>
<Card title="Reviews, approvals and gates" icon="gavel" href="/user-guides/reviews-and-approvals">
Configuring the decision points themselves.
</Card>
<Card title="Permissions and roles" icon="lock-keyhole" href="/user-guides/permissions-and-roles">
Custom roles built from resource, action and scope.
</Card>
</CardGroup>
# Asking your documents a question
Source: https://docs.coverbase.com/user-guides/document-evidence-pull
Ask a plain-English question in chat and get back the passage from a vendor's documents that answers it: the verbatim quote, its page, a cropped image of the highlighted passage, and a link that opens the document on that page with the passage marked.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It runs through the [Coverbase MCP server](/mcp/overview), so you need a connected assistant. Setup is in [Connecting](/mcp/connecting).
</Info>
A **document evidence pull** answers a question out of a vendor's stored documents. You ask something like "does the SOC 2 cover encryption of data at rest?" and Coverbase decides which one or two documents are worth reading, reads them, and comes back with the passage that answers you.
The answer comes with its source attached: the sentence as it appears in the document, the page it sits on, an image of that page with the sentence marked, and a link that opens the document there.
<Note>
This is different from [Document Insights](/user-guides/document-insights). Insights are fields you configure once and Coverbase populates on every matching document. An evidence pull is a one-off question you ask in the moment, about anything, with no configuration.
</Note>
## What you get back
<CardGroup>
<Card title="A direct answer" icon="comment">
One or two sentences answering the question, per document read.
</Card>
<Card title="A verbatim quote" icon="quote-left">
The exact span from the document that supports the answer, checked against the document text before it is returned. If no quote could be grounded, the answer says so and you should treat it as unverified.
</Card>
<Card title="A page number" icon="file-lines">
Where the quote sits in the document. Excel workbooks report a sheet name instead.
</Card>
<Card title="A snippet image" icon="image">
A crop of the page with the quote highlighted, rendered during the pull and displayed inline in chat.
</Card>
<Card title="A highlighted deep link" icon="link">
Opens the document in Coverbase on the right page with the passage marked. Details in [The highlighted link](#the-highlighted-link).
</Card>
<Card title="A confidence" icon="gauge">
**High** when the document states it outright, **medium** when it had to be inferred, **low** when the model was unsure.
</Card>
</CardGroup>
***
## Running one
### The scripted way
Invoke the `pull_document_evidence` prompt from your client's prompt menu and give it a vendor name and a question. It runs the whole sequence: resolve the vendor, look at what documents exist, start the pull, wait for it, and report each answer with its quote, page, image and link. See [Canned prompts](/mcp/prompts).
### The conversational way
Ask in plain language. All of these start a pull:
<AccordionGroup>
<Accordion title="A question about one vendor's evidence" icon="comment-dots">
> Does Acme's SOC 2 cover encryption of data at rest?
The assistant resolves Acme, sees which documents you hold, and starts a pull scoped to that vendor. If several vendors match the name it asks which one rather than guessing.
</Accordion>
<Accordion title="A question narrowed to a document type" icon="filter">
> What is the notice period for termination in Acme's MSA?
Naming the kind of document narrows the candidate set before anything is read. You do not have to: the selection step is usually right without it. It helps most when a vendor has dozens of documents and the question points at one type.
</Accordion>
<Accordion title="A question about one specific document" icon="file">
> In the Acme penetration test report, were any critical findings left unresolved?
When you name a document, that document is what gets read. No selection step.
</Accordion>
<Accordion title="A question scoped to a service" icon="server">
> For the Acme Data Warehouse service, does any document say where data is stored?
Restricts the candidate set to documents attached to that service.
</Accordion>
<Accordion title="A question about a period" icon="calendar">
> What did Acme's most recent SOC 2 say about change management? Only look at documents uploaded this year.
The pull itself has no upload-date filter. The assistant uses upload dates when it lists the vendor's documents, and then points the pull at the document it found, or you can name that document yourself.
</Accordion>
</AccordionGroup>
### It takes a couple of minutes
Starting a pull returns a **run id**, not the answer. The file is fetched, a model reads it, and the passage is located and rendered. A typical pull finishes in one to three minutes, and a long document can take longer.
Your assistant should tell you it is running and then collect the result. If it goes quiet, ask it to check the run.
<Warning>
Do not start a second pull because the first has not come back. Each pull reads documents at full cost. Ask for the result of the run you already have.
</Warning>
***
## A worked example
You ask:
> Does Acme encrypt customer data at rest? Check their SOC 2.
The assistant starts the pull and tells you so:
```
Reading documents to answer: Does Acme encrypt customer data at rest?
Run `cbdevr_01JB2X...` is queued. This takes a couple of minutes.
```
A minute or two later it collects the result:
```markdown theme={null}
# Evidence for: Does Acme encrypt customer data at rest?
Read 1 of 14 readable document(s) in scope, with 6 previously cited
passage(s) available to reuse. Quotes are verbatim from the document.
Selection: The SOC 2 Type 2 report is the only document in scope that
describes encryption controls; the DPA and the MSA cover obligations
rather than implementation.
## Acme Cloud SOC 2 Type II 2025.pdf (SOC 2 Type 2 Auditor Report)
- **Answer:** Yes. Customer data is encrypted at rest with AES-256, with
keys managed in AWS Key Management Service.
- Confidence: high
- **Quoted (page 12):** > All customer data is encrypted at rest using
AES-256 with keys managed in AWS Key Management Service, and encrypted
in transit using TLS 1.2 or higher.
- [Open highlighted in Coverbase](https://your-coverbase-url/vendors/cbvndr_.../documents/cbvdoc_...?page=12&highlight=All+customer+data+is+encrypted...)
- 
```
The `![Evidence snippet]` line renders in chat as a crop of the page with the passage marked:
<Frame>
<img alt="A crop of a SOC 2 report page. Under the heading CC6.7 Encryption, the sentence beginning All customer data is encrypted at rest using AES-256 is highlighted in yellow across two lines. The unhighlighted CC6.1 Logical Access and CC7.2 Monitoring controls sit above and below it." />
</Frame>
Cite the quote and the link rather than the answer. They are what show where the answer came from.
***
## How Coverbase decides what to read
Reading every document a vendor has for every question would be slow and expensive, so a pull narrows in stages.
<Steps>
<Step title="Filter on metadata">
Your document type and service filters, or the one document you named, are applied in the database first. Nothing is read yet. At most 100 documents survive as candidates.
</Step>
<Step title="Gather what was already quoted">
Coverbase collects passages that earlier work already quoted from those same documents, along with the images already rendered for them. This is what makes a repeat question cheap.
</Step>
<Step title="Let a model pick">
A model sees the candidate list (names, types, upload dates) and those earlier passages, and picks the one or two documents most likely to hold the answer. It also decides whether an earlier passage already answers the question outright. Its reasoning comes back to you as the **Selection** line.
</Step>
<Step title="Read only those">
The chosen documents are read in full. By default at most two, and never more than five.
</Step>
<Step title="Locate and render the passage">
Each quote is located in the page and cropped with the passage highlighted. If a matching image was already rendered for that passage, it is reused rather than made again.
</Step>
</Steps>
<Tip>
Read the **Selection** line when an answer is not what you expected. Usually a different document was picked than the one you had in mind, and the line says which and why. Name the document explicitly to override it.
</Tip>
### Asking the same thing twice is cheap
When a passage has already been quoted and rendered, a later pull can answer from it without reading the document again. You will see this in the header:
```
Read 0 of 3 readable document(s) in scope, with 4 previously cited
passage(s) available to reuse.
```
`Read 0` means nothing had to be opened. The finding will say **Source: a passage already cited from this document**, and the snippet image is the one rendered earlier. The answer is grounded in the same verbatim text either way.
Coverbase never reuses a passage whose underlying insight has since been re-extracted, so a stale image cannot ground a new answer.
***
## The highlighted link
Every answer carries a link of this shape:
```
https://<your Coverbase URL>/vendors/<vendor>/documents/<document>?page=42&highlight=<the+quote>
```
Opening it loads the document preview, jumps to that page, and marks the passage.
The highlight travels as the quote itself rather than as coordinates on the page. If the document is re-processed and the layout moves, the viewer re-matches the text and still finds it, where a stored box would point at the wrong place. It also keeps the link readable, so you can see what it will highlight before you click.
<Note>
The link opens Coverbase and respects your permissions. Someone without access to that vendor sees your normal access error, not the document. Sharing the link with a colleague is safe.
</Note>
<Warning>
The snippet **image** in the chat response is a short-lived link that expires about an hour after the result is collected. The Coverbase link does not expire. When you paste evidence into a ticket or a report, paste the Coverbase link, and save the image itself if you need it to persist.
</Warning>
***
## What can and cannot be read
<AccordionGroup>
<Accordion title="Scanned documents work" icon="scanner">
Coverbase OCRs documents on ingestion and keeps a searchable rendition alongside the original. A pull reads that rendition, so a scanned PDF that has finished processing is readable and its passages can be highlighted. Quality follows the scan: a clean scan reads like a native PDF, a photographed page at an angle may not.
</Accordion>
<Accordion title="Excel workbooks read the original file" icon="file-excel">
A workbook is read as a workbook rather than as its PDF rendition, because converting to PDF loses the cell structure. Answers from a workbook cite a **sheet name** instead of a page number, and do not carry a snippet image.
</Accordion>
<Accordion title="A document still processing is skipped" icon="hourglass">
A document that has not finished ingestion has no readable rendition yet, so it is not a candidate. Wait for it to finish and ask again.
</Accordion>
<Accordion title="Very large documents may be declined" icon="weight-hanging">
A document past the live-analysis size limit reports **Could not read this document** with the reason, rather than silently dropping out of the answer.
</Accordion>
<Accordion title="A document that answers nothing says so" icon="circle-minus">
If a document was read and does not address the question, the finding says **No answer to this question in this document**. This usually means the clause you expected is not in the vendor's paper.
</Accordion>
</AccordionGroup>
***
## Reading the answer critically
<AccordionGroup>
<Accordion title="An answer without a quote is unverified" icon="triangle-exclamation">
When the model could not ground its answer in a verbatim span, the response says: **No verbatim quote was grounded in the document, treat the answer as unverified.** Open the document and check it yourself before using the answer.
</Accordion>
<Accordion title="Check what the answer does not cover" icon="list-check">
The header says how many documents were read out of how many were in scope. `Read 2 of 40` means thirty-eight documents were not opened. The answer is what those two say, not a statement about your whole repository.
</Accordion>
<Accordion title="Confidence is the model's, not a measurement" icon="gauge">
**Medium** or **low** means the model had to infer. The quote is still verbatim; what is uncertain is whether that quote means what the answer says it means.
</Accordion>
<Accordion title="Widen the scope before concluding nothing exists" icon="magnifying-glass-plus">
"None of the documents read answered the question" is not "the vendor has no such control". Drop the document-type filter, raise the document limit, or ask about a specific document you believe holds the answer.
</Accordion>
</AccordionGroup>
***
## Limits
| Limit | Value |
| - | - |
| Documents read per pull | 2 by default, 5 maximum |
| Candidate documents considered | 100 |
| Concurrent pulls per organization | 3 |
| Typical duration | 1 to 3 minutes |
| Snippet image link lifetime | About 1 hour |
| Coverbase deep link lifetime | Permanent |
A pull that has not reported back within about 25 minutes is reported as stalled. The first pull will not return a result, so start another one.
***
## Permissions and audit
A pull reads only documents you can already see. It runs under your organization and your permissions, exactly like opening the document in the dashboard.
Asking a question does not require write access. The pull records its own question and answer so the result can be collected later, and that record is the only thing it writes. It creates nothing you manage elsewhere: no finding, no note, no document.
Every pull is captured in the MCP audit log with the tool called, the user, the organization, and the timestamp. See [Permissions](/mcp/permissions) and [Security](/mcp/security).
***
## Related
<CardGroup>
<Card title="Document Insights guide" icon="file-magnifying-glass" href="/user-guides/document-insights">
Fields pulled from every document of a type automatically, with the same quote and page citation.
</Card>
<Card title="Evidence quality" icon="file-shield" href="/user-guides/evidence-quality">
What makes a document usable as evidence in the first place.
</Card>
<Card title="Canned prompts" icon="wand-magic-sparkles" href="/mcp/prompts">
`pull_document_evidence` and the nineteen other scripted workflows.
</Card>
<Card title="Tool reference" icon="screwdriver-wrench" href="/mcp/tool-reference">
The exact routes behind a pull, for auditing what an assistant did.
</Card>
</CardGroup>
# Document expiry reminders
Source: https://docs.coverbase.com/user-guides/document-expiry-reminders
How Coverbase reminds you before a vendor document lapses: which dates it fires from, who receives the email, and where to see everything that is expiring.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers reminders on vendor documents: certificates of insurance, SOC reports, ISO certificates and anything else with an expiry. For reminders on the dates in a contract record, see [Contract dates and reminders](/user-guides/contract-dates-and-reminders).
</Info>
A certificate of insurance lapses. A SOC 2 report goes stale. An ISO certificate reaches its expiry. Coverbase can email someone before each of those happens, and this guide covers the three decisions you make: **when** the email goes out, **who** receives it, and **where** you see what is coming.
## Where reminders are configured
Two places, one editor. Whichever you use, you are editing the same org-wide policy.
<CardGroup>
<Card title="From a document" icon="file">
Open the vendor, open the document, then **Actions → Configure notifications**. The document's type is already selected.
</Card>
<Card title="From Documents" icon="folder-open">
Go to **Configuration → Documents → Reminders** for every reminder your organization has, in one table.
</Card>
</CardGroup>
<Warning>
Reminders apply to **every document of that type, across every vendor**, not to the one document you opened. Changing the certificate of insurance reminder changes it for all of them.
</Warning>
## When the reminder fires
A reminder is one or more conditions, each an offset from a date on the document:
* **30 days before** the policy expiration date
* **on** the policy expiration date
* **7 days after** it, to chase a certificate that never arrived
Which dates you can choose from depends on the document type. A certificate of insurance offers its policy expiration date, policy effective date and certificate date. A SOC report offers its publication date and audit period dates. A certification such as ISO 27001 offers its expiry, issue and next audit dates, and a PCI attestation its next assessment due date. Every type also offers the document's own expiration date, the one you can set by hand.
### Certificates covering several policies
A certificate of insurance often covers general liability, auto, umbrella and workers' compensation, each with its own expiry. Coverbase treats each coverage line as its own date, so a reminder fires ahead of each one. Two policies expiring on the same day produce one email that names both, rather than two that look like duplicates.
### Documents with no extracted date
Coverbase reads dates out of the documents it knows how to parse. For everything else (a professional license, a tax certificate, a zip archive) set the date yourself: open the document, then **Actions → Set expiration date**. Once it is set, that document can carry reminders like any other.
<Note>
If a condition points at a date the document does not have, the editor says so. The reminder is saved, but it cannot fire until the date exists.
</Note>
## Who receives it
Each reminder has a **To** line and a **Cc** line. Add any mix of:
| Recipient | Resolves to |
| - | - |
| **Relationship owner** | The vendor's relationship owners, and the members of any user group set as one |
| **Risk analyst** | The vendor's risk analysts, and the members of any user group set as one |
| **Watcher** | Everyone watching the vendor |
| **Uploaded by** | Whoever uploaded that document |
| **Vendor contact** | The vendor's own contacts. An external recipient, so the picker flags it |
| A person | One named user, the same for every vendor |
| A user group | Every active member of that group |
| An email address | Anything you type, the same for every vendor |
Roles resolve per vendor when the reminder fires, so "risk analyst" means *that vendor's* risk analyst.
<Tip>
To route certificate expiries to your risk analysts instead of the relationship owner, put **Risk analyst** on the To line and move **Relationship owner** to Cc, or take it off entirely.
</Tip>
### If nobody resolves
Everyone on either line gets their own email. If no To recipient resolves for a vendor (for example, nobody is assigned as its risk analyst), the Cc recipients still receive it, so the reminder still lands. If neither line resolves to anyone, no email is sent for that vendor.
Reminders to people in your organization also appear in their Coverbase notifications and follow each person's own notification settings. Addresses outside it, such as a vendor contact or a typed email, are emailed directly.
## Seeing what is expiring
**Configuration → Documents → Expirations** lists every date across every document, soonest first, with:
* how long until it expires, or how long ago it passed
* which coverage line it belongs to, on a certificate covering several
* whether a reminder covers that date at all
Filter by window to answer two questions: what has **already passed**, and what expires in the **next 30 days**.
<Note>
A row marked **No rule** has a date nobody is being reminded about. That is usually the row to act on first.
</Note>
## When reminders go out
Once a day. A reminder set for "30 days before" goes out on the day that is exactly 30 days ahead of the date, not repeatedly through the month. Add several conditions if you want several nudges.
## Related
<CardGroup>
<Card title="Contract dates and reminders" icon="calendar" href="/user-guides/contract-dates-and-reminders">
Reminders on the dates in a contract record.
</Card>
<Card title="Email notifications" icon="envelope" href="/user-guides/email-notifications">
Every email Coverbase sends, and who receives it.
</Card>
<Card title="Document Insights guide" icon="file-magnifying-glass" href="/user-guides/document-insights">
The fields Coverbase reads out of each document, including its dates.
</Card>
</CardGroup>
# Document Insights guide
Source: https://docs.coverbase.com/user-guides/document-insights
Define the fields Coverbase pulls out of every document: how to write an insight, when to use Extract vs Synthesize, a starter library you can copy, and how to check the results.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It pairs with the [Contract Guardian guide](/user-guides/contract-guardian), which covers clause sets and clause reviews. Insights are the *field-level* half of contract intelligence; clause review is the *language-level* half.
</Info>
A **document insight** is a field you want pulled out of every document of a given type. You define it once (a name, a description, a type, and a mode), and from then on Coverbase populates it automatically whenever a matching document is processed, with a page citation and a verbatim source quote attached to the value.
Insights are not limited to contracts. Any document type can carry them: an insurance certificate's coverage limit, a SOC 2's audit period, a DPA's subprocessor notification window. Contracts are where most teams start, because the same fifteen questions get asked of every agreement.
<Tip>
The most common setup mistake is writing insights as if the AI can see your intent. It cannot. It sees the insight name, your description, the type, and the mode. Everything in this guide comes back to making those four things carry the meaning.
</Tip>
## What you get for each insight
Every extracted value arrives with:
<CardGroup>
<Card title="The value" icon="hashtag">
Stored in its declared type: text, a parsed number, an ISO date, or a boolean. Dates normalize to `YYYY-MM-DD`; numbers strip currency symbols and separators.
</Card>
<Card title="A verbatim source quote" icon="quote-left">
The exact span from the document that supports the value. Coverbase checks that the quote appears in the document. An answer whose quote cannot be located is kept, marked **Supporting evidence not verified** at low confidence, and waits for a reviewer to **Accept answer**.
</Card>
<Card title="A page citation" icon="file-lines">
The 1-indexed page where the quote lives. If the model cites the printed page label instead of the physical page, Coverbase corrects it to the page the quote was found on.
</Card>
<Card title="A confidence and a rationale" icon="gauge">
**High** when the document states it explicitly, **medium** when it had to be inferred, **low** when the model was unsure. Plus short notes on any ambiguity or assumption.
</Card>
</CardGroup>
<Note>
When a document does not contain the answer, the insight comes back empty rather than guessed. An empty insight is a finding rather than a failure, and it usually means the clause is missing from the vendor's paper.
</Note>
## Where insights show up
<AccordionGroup>
<Accordion title="On the document itself" icon="file">
Open any document and switch to the **Insights** tab. This is the full view: every insight configured for that document type, with values, confidence, source quotes, and page links. From here you can accept an unverified answer, re-extract, export the whole set to CSV, or **Add insight**: define one, preview what it extracts from this document, and save it for every document of this type.
</Accordion>
<Accordion title="On the contract record" icon="file-contract">
The **Extracted insights** card on a contract's **Documents** tab rolls up insights across every linked document, grouped by field. Insights with no extracted value are hidden here to cut noise. Open the individual document to see the blanks.
</Accordion>
<Accordion title="Inside the contract AI summary" icon="sparkles">
Extracted insights are fed to the model that writes the contract summary and populates the contract risk profile. Better insights produce a better summary, so the two improve together.
</Accordion>
<Accordion title="In exports" icon="download">
**Export CSV** on the document Insights tab produces one row per insight with the value, all four typed columns, confidence, source quote, page number, reasoning, and whether the value was AI-extracted or entered manually.
</Accordion>
</AccordionGroup>
## When extraction runs
1. **Automatically, on upload.** When a new document finishes processing, Coverbase extracts every enabled insight whose document types match that document.
2. **On demand, per document.** Open a document's Insights tab and choose **Refresh all**. Use this after you add or reword an insight, since existing documents were processed against the old definition.
3. **On demand, per insight.** Re-extract a single insight from the row's actions after you tighten its description.
4. **In bulk, across history.** A new insight starts empty on every document you already hold. **Configuration → Document Insights → Document types** shows exactly how many, and a backfill re-extracts them. See [Backfilling history](#backfilling-history).
<Warning>
Adding a new insight does not fill your existing documents on its own. Until you run a backfill, the field only populates on documents processed after the change.
</Warning>
***
## Creating an insight
Go to **Configuration → Document Insights**. You need the org-settings update permission to reach this page.
<Steps>
<Step title="Create a group first (optional but recommended)">
A group is a folder that shares document-type scope with everything inside it. Set **Data protection** to apply to DPAs and MSAs once, and every insight you drag into it inherits that scope. Without groups you set document types on every insight by hand and they drift apart.
</Step>
<Step title="Add the insight and name it for a human">
**Name** is what reviewers see in the UI and in exports. Use the term your team uses: *Liability cap*, *Governing law*, *Termination notice period*. The name is also the first thing the AI reads, so a vague name costs you accuracy.
</Step>
<Step title="Write the description">
This is the instruction. See [Writing descriptions that work](#writing-descriptions-that-work) below. It matters more than every other setting.
</Step>
<Step title="Pick the type">
**Text**, **Number**, **Date**, or **Yes/No**. The type controls how the value is stored, validated, sorted, and displayed. Choosing Number for a monetary field also offers the **Currency (USD)** display format.
</Step>
<Step title="Pick the mode">
**Extract** or **Synthesize**. **Synthesize** is only available for a **Text** insight; choosing any other type switches the mode back to **Extract**. The next section covers this choice.
</Step>
<Step title="Scope it to document types">
Choose the document types this insight applies to, or inherit them from the group. **Leaving the list empty applies the insight to every document type**, which is rarely what you want: it means Coverbase will hunt for a liability cap inside a SOC 2 report.
</Step>
<Step title="Try it on a real document before you roll it out">
Open a representative document, go to its **Insights** tab and choose **Add insight**. Define the insight there and run the preview: it extracts from that one document and shows the value, the quote, the page and the confidence before anything is saved. Iterate on the description until it holds up, then save it, which scopes it to that document's type.
That is cheaper than discovering an ambiguous description after backfilling three thousand documents.
</Step>
</Steps>
***
## Extract vs Synthesize
This is the setting people get wrong most often.
<CardGroup>
<Card title="Extract: a single, typed answer" icon="pen-line">
The model returns one concise answer in the insight's type: a name, a date, a number, or Yes/No. It prefers the document's own wording, and interprets or normalizes only as far as the type needs, so a Yes/No insight reads the clause and answers Yes or No. It must cite a verbatim quote from the document, and Coverbase checks that quote. If the document does not answer, the insight comes back empty.
</Card>
<Card title="Synthesize: a written summary" icon="sparkles">
The model writes a short answer in its own words that combines or explains what the document says: rolling up several clauses, or turning legalese into a plain verdict. It still has to cite a verbatim quote from the document. Because the answer is prose, Synthesize is only available for **Text** insights. If the document cannot answer, the value comes back empty.
</Card>
</CardGroup>
Both modes are grounded. What changes between them is **the shape of the answer**: a single value you can sort and filter on, or a sentence a reviewer reads.
### The decision table
| What you want | Mode | Why |
| - | - | - |
| A date, party name, jurisdiction, or figure printed on the page | **Extract** | The exact value is what you want stored |
| A defined term lifted from the contract (*"Delaware"*, *"30 days"*, *"\$1,000,000"*) | **Extract** | Copying the document's wording is the whole point |
| A yes/no that depends on reading a clause | **Extract** | A Yes/No insight reads the clause and answers Yes or No, with the clause quoted |
| A number or date the contract implies but never prints | **Extract** | The answer is still one typed value; say in the description how to work it out |
| A rollup across several sections or documents | **Synthesize** | No single value contains the answer |
| A plain-language verdict (*"Mutual, capped at 12 months' fees"*) | **Synthesize** | You want an explanation, not a value |
| The gist of a clause every counterparty words differently | **Synthesize** | A summary is what normalizes it |
| Anything phrased identically on every document (your own paper, invoices, certificates) | **Extract** | Highest precision, no interpretation drift |
### Yes/No insights
<Warning>
A **Yes/No** insight is always **Extract**, because Synthesize only takes Text. That works: Extract answers Yes or No even though neither word appears in the contract, and quotes the clause it relied on. Insights created earlier as Yes/No with Synthesize now run as Extract, so they need no change.
</Warning>
Write a Yes/No description as the question, and say what counts as Yes. "Do we have audit rights?" reads Section 8.3, answers **Yes**, and cites the clause. Where the answer turns on nuance (notice periods, conditions), the quote carries the nuance and the value stays filterable.
### The same question, both ways
Take one requirement (*do we have the right to run a penetration test?*) and see how the mode changes what you get.
<Tabs>
<Tab title="Extract">
**Name:** Pen test rights granted
**Type:** Yes/No · **Mode:** Extract
**Description:** Does the customer have a contractual right to perform penetration testing or security testing against the vendor's production environment? Answer Yes only if testing is affirmatively permitted, including where it requires notice or scheduling. Answer No if testing is prohibited, or if the contract only offers third-party test summaries in place of customer testing.
**Result:** `Yes`, quoting *"Customer may, no more than once per twelve (12) month period and upon thirty (30) days' prior written notice, conduct penetration testing of the Services."* on page 14, confidence high.
Good when you want to sort your portfolio by which vendors you can test. The nuance about notice periods lives in the quote; the filterable answer lives in the value.
</Tab>
<Tab title="Synthesize">
**Name:** Penetration testing terms
**Type:** Text · **Mode:** Synthesize
**Description:** Summarize the customer's right to penetration-test the vendor's systems: whether it is permitted, how often, and on what notice. Answer "None stated" if the contract is silent.
**Result:** `Permitted once every twelve months on 30 days' written notice`, quoting the same sentence on page 14, confidence high.
Good when a reviewer wants the terms in one line. Useless for filtering, because every vendor's terms read differently.
</Tab>
</Tabs>
<Tip>
Many teams run **both**: a Yes/No Extract field for the dashboard and a companion Synthesize field summarizing the terms. They cost one extra pass each and answer two different jobs.
</Tip>
### Quick rules
* If you want one value you could sort or filter on (a date, a number, a name, Yes or No), use **Extract**.
* If you would have to read a paragraph and then say a sentence back, use **Synthesize** on a Text insight.
* Every Yes/No, Number and Date insight is **Extract**. Synthesize takes Text only.
* A Number or Date you would have to work out is still **Extract**; put the working in the description.
* When you cannot decide on a Text insight, start with **Synthesize**. You get an answer with a quote attached, and you can tighten to Extract later once you have seen how the language reads.
<Note>
Mixing modes across your insight set is normal and costs nothing. Coverbase groups insights by mode and runs each group as its own pass over the document.
</Note>
***
## Writing descriptions that work
The description is the prompt. Treat it like an instruction to a sharp new analyst who has never seen your contracts and will not ask follow-up questions.
A description that performs well usually has four parts:
<Steps>
<Step title="Define the thing precisely">
"The maximum aggregate liability cap that applies to the vendor" beats "liability".
</Step>
<Step title="Name the aliases">
List the headings the clause hides under: *Limitation of Liability*, *Liability Cap*, *Maximum Liability*, *Limitations on Liability*.
</Step>
<Step title="Say what to do about edge cases">
"If the cap is expressed as a multiple of fees, return the multiple and the lookback period. If liability is uncapped, return 'Uncapped'."
</Step>
<Step title="Say what not to return">
"Do not return the indemnification carve-out amounts. Do not return the customer-side cap." Exclusions prevent the most common wrong answers.
</Step>
</Steps>
<Tabs>
<Tab title="Weak">
**Name:** Liability
**Description:** *(empty)*
**Type:** Text · **Mode:** Extract
Returns something from the liability section, but which sentence varies by document. On a contract with asymmetric caps you cannot tell whose cap you got.
</Tab>
<Tab title="Strong">
**Name:** Vendor liability cap
**Description:** The maximum aggregate amount the vendor can be liable for under this agreement. Look under headings such as Limitation of Liability, Liability Cap, Maximum Liability, or Limitations on Liability, including all-caps blocks beginning "IN NO EVENT". If the cap is a multiple of fees, state the multiple and the lookback window (for example, "1x fees paid in the preceding 12 months"). If the vendor's liability is uncapped, answer "Uncapped". Ignore the customer's payment obligations and any super-cap that applies only to indemnification carve-outs.
**Type:** Text · **Mode:** Synthesize
Returns a comparable answer across every contract, with the operative clause quoted underneath.
</Tab>
</Tabs>
<Tip>
When an insight misfires, read the **reasoning** on the extracted value before you change anything else. It usually says which sentence the model picked, and the fix is one exclusion sentence in the description.
</Tip>
***
## A starter library
There is no packaged template for insights the way there is for [clause sets](/user-guides/contract-guardian#start-from-the-clause-set-library). Insight definitions are yours to write, because they encode what your program tracks. Use this as the copy-and-adapt starting point. Group them, scope them to your contract document types, and delete anything you will not use.
### Group: Contract basics
Scope to MSA, order form, SOW, terms of service, software license agreement.
| Insight | Type | Mode | Description to start from |
| - | - | - | - |
| Counterparty legal name | Text | Extract | The full legal entity name of the vendor as written in the preamble, including the corporate suffix (Inc., LLC, Ltd., GmbH). Not the trading or brand name. |
| Effective date | Date | Extract | The date the agreement becomes effective, as stated in the preamble or signature block. If both an execution date and an effective date appear, return the effective date. |
| Initial term end date | Date | Extract | The date the initial term ends. If the contract states a duration rather than an end date, calculate it from the effective date and return the resulting date. |
| Governing law | Text | Extract | The jurisdiction whose laws govern the agreement, from the Governing Law or Applicable Law clause. Return the jurisdiction only (for example, "Delaware", "England and Wales"), not the venue or arbitration seat. |
| Total contract value | Number | Extract | The total contract value or annual subscription fee as printed on the order form or fee schedule. Return the figure only. Display as currency. |
| Payment terms | Text | Extract | The payment window stated in the Payment or Fees clause, for example, "Net 30", "Net 45", "due upon receipt". |
### Group: Renewal and exit
Scope to MSA, order form, terms of service.
| Insight | Type | Mode | Description to start from |
| - | - | - | - |
| Auto-renews | Yes/No | Extract | Does the agreement renew automatically at the end of the term absent notice? Answer Yes for evergreen or automatic renewal, No where renewal requires an affirmative written order or signature. |
| Termination notice period (days) | Number | Extract | The number of days' advance written notice the customer must give to terminate or prevent renewal. Convert months to days (one month = 30 days). If notice periods differ for convenience and for cause, return the notice period for termination for convenience. |
| Termination for convenience | Yes/No | Extract | May the customer terminate without cause? Answer Yes only where termination for convenience is available to the customer, and No where termination requires cause, breach, or vendor consent. |
| Data return and deletion | Yes/No | Extract | Does the agreement obligate the vendor to return or delete customer data on termination? Answer Yes only where return or deletion is an obligation, not merely available on request at the customer's cost. |
| Exit assistance | Text | Synthesize | Summarize any transition, migration, or exit-assistance obligations the vendor owes at the end of the term, including duration and whether they carry additional fees. Answer "None stated" if the contract is silent. |
### Group: Risk and liability
Scope to MSA, DPA, security addendum.
| Insight | Type | Mode | Description to start from |
| - | - | - | - |
| Vendor liability cap | Text | Synthesize | The maximum aggregate amount the vendor can be liable for. If expressed as a multiple of fees, state the multiple and the lookback window. Answer "Uncapped" where the vendor's liability is not limited. Ignore any super-cap applying only to indemnification carve-outs. |
| Liability cap carve-outs | Text | Synthesize | Which categories of claim sit outside the liability cap? List them (for example, confidentiality breach, data breach, IP indemnity, gross negligence, willful misconduct). Answer "None" where the cap applies to all claims. |
| Mutual indemnification | Yes/No | Extract | Do both parties owe indemnification obligations to each other? Answer No where only the customer indemnifies the vendor, or only the vendor indemnifies the customer. |
| Cyber insurance required | Yes/No | Extract | Does the agreement require the vendor to carry cyber liability or technology errors-and-omissions insurance? Answer Yes only where it is a stated obligation with or without a coverage amount. |
| Cyber insurance limit | Number | Extract | The per-occurrence or aggregate coverage limit stated for cyber liability or technology E\&O insurance in the Insurance clause. Return the figure only. Display as currency. |
### Group: Data protection and security
Scope to DPA, MSA, security addendum, SCC.
| Insight | Type | Mode | Description to start from |
| - | - | - | - |
| Breach notification window (hours) | Number | Extract | How many hours does the vendor have to notify the customer of a security incident or personal data breach? Convert days to hours. If the contract says only "without undue delay" with no fixed period, leave empty. |
| Subprocessor change notice | Yes/No | Extract | Must the vendor give advance notice before engaging a new subprocessor? Answer Yes where notice is required, whether or not the customer can object. |
| Audit rights | Yes/No | Extract | May the customer audit the vendor's security controls, whether directly or through an independent auditor? Answer No where the vendor offers only its own SOC 2 or ISO certificate in place of an audit right. |
| Data residency commitment | Text | Synthesize | Where does the vendor commit to store and process customer data? Return the countries or regions named. Answer "None stated" where the contract makes no residency commitment. |
| Data protection framework | Text | Extract | The transfer mechanism named in the agreement, for example, "Standard Contractual Clauses", "EU-US Data Privacy Framework", "UK Addendum". |
### Group: Service levels and AI
Scope to SLA, MSA, AI addendum.
| Insight | Type | Mode | Description to start from |
| - | - | - | - |
| Uptime commitment | Number | Extract | The committed availability percentage from the service level agreement, for example, 99.9. Return the number only, without the percent sign. |
| Service credit cap | Text | Synthesize | The maximum service credits available for missed service levels, usually expressed as a percentage of fees for the affected period. Answer "None stated" where the contract commits to service levels without credits. |
| Customer data used for model training | Yes/No | Extract | Does the agreement permit the vendor to use customer data or customer content to train, fine-tune, or improve its AI or machine learning models? Answer Yes where permitted by default, No where prohibited or opt-in only. Leave empty where the contract is silent on AI. |
| AI output ownership | Text | Synthesize | Who owns the outputs generated by any AI features? Return the owning party and any conditions. Answer "None stated" where the contract does not address AI outputs. |
| Human review of AI decisions | Yes/No | Extract | Does the agreement commit the vendor to human oversight or review of automated decisions affecting the customer? |
<Note>
In this library, **Extract** appears wherever the answer is a single value (dates, jurisdictions, figures, named frameworks, Yes/No), and **Synthesize** where the answer is a written judgment. Every Synthesize row is a Text insight, because that is the only type Synthesize takes.
</Note>
***
## Auditing coverage
Writing an insight is the easy half. Knowing whether it worked across your whole corpus decides whether anyone trusts the field.
**Configuration → Document Insights** answers that. Three tabs over the same data:
<AccordionGroup>
<Accordion title="Insights: is each definition healthy?" icon="list-check">
Your library, with coverage on every row: how many eligible documents carry a value, how many of those had verified evidence, and how many are waiting for a human to accept an unverified answer. Select several rows to enable, disable, rescope, regroup, archive, or backfill them in one action.
</Accordion>
<Accordion title="Document types: is this type well covered?" icon="table-cells">
A matrix: document types down the side, insights across the top, a fill rate in every cell. This view answers "what do we extract from an MSA, and how well?"
An em-dash means the insight is not scoped to that document type. A percentage means it is.
</Accordion>
<Accordion title="Extractions: is this specific value right?" icon="magnifying-glass">
Every extraction in the org, filterable by insight, confidence, whether the quote was grounded, review state, and whether the value came from AI or was set manually.
Filter to **Needs review**, or to low confidence and **Not grounded**, and you have a review queue. Click any row to open that document with the Insights tab already scrolled to the value in question, so you never leave the list to check a value.
</Accordion>
</AccordionGroup>
### Two kinds of blank
A missing value means one of two opposite things:
| What you see | What it means | What to do |
| - | - | - |
| **Attempted, no value** | Extraction ran and found nothing | Read the values on the Extractions tab. Usually the description is ambiguous, or the mode is wrong, or the clause is not in the vendor's paper |
| **Stale** (amber badge) | The insight was created after the document was last processed, so it has never run against it | Backfill. The badge is the button |
<Tip>
A brand-new insight shows 100% stale and 0% filled. That means the definition has not run yet. Backfill first, *then* judge the fill rate.
</Tip>
***
## Backfilling history
A backfill re-extracts documents you already hold, so a new or reworded insight applies to your whole corpus instead of only to what arrives next.
<Steps>
<Step title="Scope it">
Pick the insights, and optionally narrow by document type or vendor. Starting from a stale badge in the coverage matrix pre-fills the scope for you.
</Step>
<Step title="Choose what to re-run">
**Only never attempted** (the default) only touches documents the insight has never run against. **Missing values** also re-runs documents that were attempted and came back empty; use this after rewording a description. **Every eligible document** re-runs everything, replacing existing AI values.
</Step>
<Step title="Read the estimate">
Before you confirm, Coverbase tells you how many documents it will process and roughly how many model calls that costs. Extraction batches every matching insight into one pass per document, so adding insights to a backfill is close to free. Adding documents is what costs.
</Step>
<Step title="Watch it run">
A progress bar tracks dispatch. Large backfills run for a while; you can leave the page, and you can cancel, which stops further documents being queued.
</Step>
</Steps>
<Note>
A backfill never overwrites a value someone set by hand, in any mode. A value someone cleared by hand is left alone too, unless you tick **Re-extract these too, replacing what was cleared** when the dialog offers it.
</Note>
<Warning>
Backfills are capped per run and per day. If a scope is too large, narrow it by document type or vendor and run it in batches. The cap exists so a single click cannot spend an unbounded amount on model calls.
</Warning>
***
## Retiring an insight
Three actions, easy to confuse:
| Action | What happens | Reversible |
| - | - | - |
| **Disable** | Stops extracting. The insight stays in your working set and its values stay visible | Yes |
| **Archive** | Retires the definition. Stops extracting, hides it from documents, keeps every value ever extracted | Yes, restore it any time |
| **Delete** | Permanently removes the definition **and every value ever extracted for it**, including hand corrections | **No** |
<Warning>
Delete is not the safe default. It is only available on an already-archived insight, it tells you exactly how many extracted values it will destroy, and it makes you type the insight's name to confirm. Archive is almost always what you want.
</Warning>
***
## Promoting an insight to a custom field
An insight lives on a document. Your team works from vendor, contract, and assessment records. Promotion carries the value across.
<Steps>
<Step title="Open the insight and choose Promote to custom field">
**Link an existing field** of a compatible type, or **Create a new field** from the insight's name and type.
Text fills Text, Number fills Number, Date fills Date, Yes/No fills True/False. Select and multi-select are not supported.
</Step>
<Step title="Set the gates">
**Require a grounded quote** (on by default) skips answers whose quote could not be located in the source. **Minimum confidence** skips anything below the bar. Together these decide how conservative the promotion is.
</Step>
<Step title="Choose what happens when the field already has a value">
**Never overwrite** only ever fills an empty field. **Fill if empty** also refreshes a value this same insight wrote before. **Latest document wins** additionally replaces values written from older documents, which is the right choice for a vendor-level field fed by many documents.
</Step>
<Step title="Backfill the field">
Leave **Backfill existing values** checked and Coverbase populates the field across every document you already hold.
</Step>
</Steps>
<Note>
A promoted value keeps a link to the document, page, and verbatim quote it came from, so a field on a contract record can show a reviewer *why* it holds that value.
</Note>
<Warning>
Promotion never overwrites a value a person typed: not on backfill, not on a later upload, not under any conflict policy.
</Warning>
***
## Sharing a library between orgs
Insight definitions can be exported as a JSON file (names, descriptions, types, modes, and document-type scope, with no values and no ids) and imported into another org. This runs through the Coverbase API rather than a button in the dashboard.
An import matches on the insight's stable key. Existing definitions are skipped unless the import explicitly opts into overwriting them, so reimporting a shared library never silently reverts local prompt tuning.
The **Export** on a single insight's page is different: it downloads that insight's extractions as a workbook (document, vendor, value, confidence, grounding, page and quote).
***
## Reviewing and correcting values
The AI drafts; a reviewer checks the evidence before anyone relies on it.
<AccordionGroup>
<Accordion title="Check the quote before you trust the value" icon="quote-left">
Expand any insight on the document's **Insights** tab to see the source quote, page number, confidence, and the model's reasoning. Scan low-confidence values first; they are flagged because the model was not sure.
</Accordion>
<Accordion title="Accept an answer whose evidence was not verified" icon="pen">
When the quote could not be located in the document, the insight reads **Supporting evidence not verified**. Check the answer against the document, then choose **Accept answer** to record that a reviewer accepted it; the evidence stays marked as unverified. The dashboard does not edit a value in place, so to change a wrong one, tighten the description and re-extract. A value set through the API is recorded as manual, is never overwritten by re-extraction or a backfill, and shows as manual in the CSV export.
</Accordion>
<Accordion title="Re-extract after you change a definition" icon="arrows-rotate">
Changing a description does not retroactively update values that were already extracted. Use **Refresh all** on a document, or re-extract a single insight from its row, once you have reworded it.
</Accordion>
<Accordion title="Export for analysis" icon="table">
**Export CSV** gives you every insight for the document with all metadata: the display value, each typed column, confidence, source quote, page number, reasoning, and whether it was AI-extracted or manual. Useful for spot-auditing a batch of contracts, or for handing a legal reviewer a worksheet.
</Accordion>
</AccordionGroup>
***
## Troubleshooting
<AccordionGroup>
<Accordion title="The insight comes back empty on documents that clearly contain the answer" icon="circle-question">
Almost always one of four things:
1. **It never ran on that document.** If the insight was created after the document was processed, it has never been attempted there. Check the coverage matrix: a *stale* badge means backfill, not a broken definition.
2. **A type that does not fit the question.** A Number or Date insight only stores a value that parses as one, and a Yes/No needs a question with a yes-or-no answer. Match the type to the question, or use a Text insight.
3. **Wrong document-type scope.** If the insight is not scoped to the type that document was classified as, it never ran. Check the document's type on its detail panel, and check the insight's document types (or its group's).
4. **The description names the wrong thing.** The model looked for what you described and did not find it. Add the aliases the clause hides under.
</Accordion>
<Accordion title="A Yes/No insight keeps failing" icon="toggle-off">
Yes/No insights always run as **Extract**, which reads the clause and answers Yes or No. Write the description as the question and say what counts as Yes. If it still comes back empty, the clause is usually missing from the document or the insight is not scoped to that document type.
</Accordion>
<Accordion title="The value is right but the page number looks wrong" icon="file-lines">
Coverbase cites the *physical* page of the PDF, which often differs from the printed page label on long agreements with front matter or per-exhibit numbering. If the quote is correct, the citation is pointing at the right place.
</Accordion>
<Accordion title="The number came back as text" icon="hashtag">
A Number insight only stores a numeric value when the extracted text parses as one. Currency symbols and thousands separators are stripped automatically; ranges, footnotes, and unit suffixes are not. Tighten the description to ask for the figure alone.
</Accordion>
<Accordion title="Nothing extracts on a scanned or image-only PDF" icon="image">
Extraction is grounded against the document's text layer. When a file's pages are images, the document's **Insights** tab says **This file has no text to read**; choose **Run again** and the re-run reads the pages with character recognition. If that still finds nothing, re-upload a text-based version of the document.
</Accordion>
<Accordion title="The insight is right for one document type and noisy on another" icon="filter">
Scope it. An insight with an empty document-type list runs against every document in your library, including SOC 2s and policies. Put it in a group with the correct scope and enable inheritance.
</Accordion>
<Accordion title="I don't see Configuration → Document Insights" icon="lock">
The page requires the org-settings update permission. Ask an admin in your organization to grant it, or to make the change for you.
</Accordion>
</AccordionGroup>
## What's next
<CardGroup>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
Insights tell you what a contract *says*. Clause reviews tell you how far it sits from what you would accept. Set up your clause sets next.
</Card>
<Card title="Analyst and reviewer guide" icon="user-check" href="/user-guides/analyst-reviewer">
Where insights and clause reviews land in the day-to-day assessment workflow.
</Card>
</CardGroup>
# Due diligence methods and the portal
Source: https://docs.coverbase.com/user-guides/due-diligence-methods-and-portal
Choose how an assessment gathers evidence and schedule review sessions, let suppliers delegate questions, carry last year's answers forward, have the supplier approve reviewer edits, send service-level questions only, and raise a finding on a question.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Assessment Method** card on an assessment, service-level questions in the questionnaire editor, and the due diligence features of the supplier portal. It sits beside [How to run an assessment](/user-guides/running-an-assessment) and [The issue acceptance chain](/user-guides/issue-acceptance-chain). For what the module is, see [Due diligence](/products/due-diligence).
</Info>
Your Risk Groups gather evidence in more than one way, and vendors answer through more than one person. This guide covers the parts of due diligence that change how that happens: the assessment's method and review sessions, delegation and carried-forward answers in the portal, reviewer edits the supplier approves, and service-level sends.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
The mistake people make most often is wondering why a vendor cannot submit a questionnaire they have clearly finished. A request with carried-forward answers cannot be submitted until every one of them is confirmed or changed.
## Choose the assessment method
Open the assessment. The **Assessment Method** card in the sidebar offers:
| Method | When to use it |
| - | - |
| **Questionnaire** | The vendor answers a questionnaire through the portal. The default. |
| **Remote review** | Reviewers walk through controls with the vendor in scheduled remote sessions. |
| **Onsite** | Reviewers visit the vendor, upload what they collect, and record control effectiveness by hand. |
Changing the method needs permission to update the assessment. With **Onsite**, the card adds **Upload onsite evidence** and **Record control effectiveness**.
## Schedule a review session
On a remote or onsite assessment, click **Schedule session** on the card.
<Steps>
<Step title="Describe it">
Give a **Title**, choose the **Format** (**Remote** or **Onsite**), pick **When** (shown in your time zone) and the length in **Minutes**.
</Step>
<Step title="Say where">
Enter a **Location or Link**: a meeting link or a site address.
</Step>
<Step title="Invite people">
Choose **Internal Participants**, and type each **Vendor Attendees** email address followed by Enter. Add the **Agenda and Notes**.
</Step>
<Step title="Schedule">
Click **Schedule session**. Participants are notified with the time, place and agenda, and vendor attendees get an email.
</Step>
</Steps>
The card lists **Upcoming sessions** and **Past sessions**. Use the session's menu to **Edit** it, which notifies participants again, or **Cancel session**, which tells them by email. The next session also appears on the engagement's tracker.
## Let the supplier delegate questions
In the supplier portal, a respondent can hand parts of a questionnaire to colleagues who are portal members.
* **Who Is Answering What** lists each section with its **Owner** and **Progress**. Click **Assign** on a section to hand it to one colleague.
* **Assign several questions** lets the respondent select questions and assign them together. **Done** ends the selection.
<Frame>
<img alt="Who Is Answering What card listing an Access control section with an Assign button and an Encryption section owned by Dana Okafor, each with progress 0 of 3, and an Assign several questions link" />
</Frame>
A question assignment wins over its section's, and a section's wins over the whole form's. Each answer shows **Answered by** with the people who answered it. Nothing on your side needs configuring.
## Carry answers forward
When a vendor receives a questionnaire they have submitted before, their previous answers are copied into the new request, marked **Carried forward**. Questions are matched across versions of the questionnaire, so an edited question keeps its answer, while a question added since starts empty. Nothing already answered on the new request is overwritten.
In the portal, the vendor sees how many answers were carried forward, from which submission, and **Still accurate?** beside each. They **Confirm** an answer, or click **Confirm all** with the count, or change it. A changed answer stays marked **Updated since last time**.
On your side, the review workbench labels each answer **Carried forward, not confirmed**, **Carried forward, confirmed** or **Changed since last time**, so you can go straight to what moved.
## Have the supplier approve your edits
When a reviewer edits a vendor's answer, the vendor is asked to agree. In the portal, **Changes From** followed by your organization's name shows each edit with **Your answer** and your organization's edit. The vendor clicks **Approve edit**, or **Suggest a change** with **Suggested wording**. **Approve all** with the count approves every waiting edit at once.
<Frame>
<img alt="Changes From Harbor Consumer Brands card showing the vendor's original answer Yes struck through beside the reviewer's edited answer, a quoted reason, and a field for suggested wording with Cancel and Send suggestion buttons" />
</Frame>
In the workbench, the answer shows **Edit awaiting supplier**, **Edit approved by supplier**, **Supplier suggested a change** or **Edit superseded** (when a later edit replaced it).
## Send service-level questions only
A vendor whose company-wide due diligence is current should not answer company-wide questions again for every new service.
<Steps>
<Step title="Mark the questions">
In the questionnaire editor, turn on **Service-level question** for each question that is about the service rather than the company. Save the questionnaire first if it is new.
</Step>
<Step title="Send">
When you send the questionnaire for a new service, turn on **Send service-level questions only**. The vendor sees, and must answer, only the marked questions.
</Step>
</Steps>
The option is available only when the vendor has a completed assessment and its next assessment date has not passed. Otherwise it reads **Available once the vendor has a completed, current assessment.**
## Raise a finding on a question
In the review workbench, open an answer and choose **Raise finding on this question**. The dialog quotes the vendor's answer, and the finding records the question it was raised on. On the finding, **Raised On** shows the level (question, domain, questionnaire, assessment, service or vendor), and **Other Open Findings** lists the vendor's other open findings across assessments. A finding can also name the **Service** it applies to.
What happens next to the finding's risk is covered in [The issue acceptance chain](/user-guides/issue-acceptance-chain).
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **Assessment Method** card | The third-party lifecycle features are not turned on for your organization. | Ask your Coverbase representative. |
| A vendor attendee did not get the invitation | The address was not followed by Enter, so it was not added. | **Edit** the session and add the address. Invalid addresses are listed under the field. |
| The vendor cannot submit | Carried-forward answers are still unconfirmed. | Ask them to **Confirm all** or change each answer. |
| An answer was not carried forward | The question was added after the vendor's last submission. | Expected. The vendor answers it fresh. |
| **Send service-level questions only** is disabled | The vendor has no completed assessment, or its next assessment date has passed. | Run or complete the vendor's company-wide assessment first. |
| The vendor sees every question on an abbreviated send | No question is marked **Service-level question**. | Mark the questions in the editor and send again. |
| The vendor has not responded to an edit | Edits wait for the vendor in the portal. | Remind the vendor, or leave the edit waiting. The edited answer stands while it waits. |
## Related
<CardGroup>
<Card title="How to run an assessment" icon="list-check" href="/user-guides/running-an-assessment">
The full assessment lifecycle.
</Card>
<Card title="The issue acceptance chain" icon="list-ol" href="/user-guides/issue-acceptance-chain">
Routing a decision to accept a finding's risk.
</Card>
<Card title="The supplier portal, for suppliers" icon="user-group" href="/user-guides/supplier-portal-for-suppliers">
What your vendor sees.
</Card>
<Card title="Questionnaires" icon="clipboard-question" href="/user-guides/questionnaires">
Building and sending questionnaires.
</Card>
</CardGroup>
# Email and notifications
Source: https://docs.coverbase.com/user-guides/email-notifications
Every email Coverbase sends, who gets it, and how to change how it looks. Covers the notification catalog, per-person delivery settings, email layouts, and applying your own branding.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers what Coverbase emails out and how to control it. For the vendor-facing invitation copy itself, see **Step 8** of the [Admin and setup guide](/user-guides/admin-setup).
</Info>
Coverbase sends two kinds of email. **Notifications** go to your own team and are driven by things happening in the platform: a finding assigned to you, an assessment ready for review, an export finishing. **Vendor emails** go outside your organization: portal invitations, reminders, follow-up questions.
Both kinds share one visual system, so a reminder to a vendor and a notification to an analyst look like they came from the same company. This guide covers what gets sent, who receives it, and the three levers you have over the appearance.
## What an email looks like
Every email is built from two pieces. The **content** is what that particular email says. The **layout** is everything around it: the background, the card, the header with your logo, the footer.
<Frame>
<img alt="Example Coverbase notification email showing a finding assignment" />
</Frame>
Every email that points somewhere in the platform carries a button to that exact place. A finding notification opens that finding. An assessment reminder opens that assessment. You should never have to search for the thing an email is telling you about.
## Choosing a layout
Go to **Configuration → Communications** and scroll to **Layouts**. You set two layouts independently, and the switch at the top right of that section picks which one you are editing:
* **Internal (team)** is used for notifications to your own team.
* **External (vendors)** is used for vendor-facing email.
Setting them separately is useful when you want vendor email to carry heavy branding while internal notifications stay plain, or the reverse.
Four layouts are available under **Layout style**.
<CardGroup>
<Card title="Branded Card">
A bordered white card on a soft background, with your logo in the top left and the footer below the card. This is the default and the safest choice.
</Card>
<Card title="Minimal">
A thin accent rule across the top, then content flush against the page with no card. Lighter, closer to a plain message.
</Card>
<Card title="Left Accent">
A card with a solid bar of your brand color along its top edge. Use it when you want the color to carry more weight.
</Card>
<Card title="Plain">
No card and no chrome, so it reads like mail from a person rather than from a system. Often the best choice for vendor email, where a heavily designed template can look like marketing and get ignored.
</Card>
</CardGroup>
<Frame>
<img alt="Branded Card layout" />
</Frame>
<Frame>
<img alt="Minimal layout" />
</Frame>
<Frame>
<img alt="Left Accent layout" />
</Frame>
<Frame>
<img alt="Plain layout" />
</Frame>
Alongside the layout you can set:
| Setting | What it does |
| - | - |
| **Use brand logo** | Puts your logo in the email header. **Update in Branding** beside it opens the organization settings where the logo is set. |
| **Use brand color** | Applies your brand color to buttons and links. Without it, buttons are near-black. |
| **Font** | Inter, Lato, Arial, Georgia, or Verdana. Inter matches the application. |
| **Footer text** | A line of your own under every email, such as a mailing address or a confidentiality note, up to 2,000 characters. |
Changes save as you make them, and the **Email Preview** on the right updates to match. **Send test to myself** delivers the preview to your own address so you can check it in a real inbox. Do this before you rely on a change.
## Applying your own branding
Branding comes from what you have already set in **Configuration → Organization → Branding**. You do not configure it a second time for email.
Two logo slots exist there, and they are used differently:
* The **Full Logo** is a wordmark, meaning a logo with your company name in it. It sits alone in the email header, since it already carries your name.
* The **Logo** is a square icon. It appears next to your organization name as a pair, the same way it does in the platform's left navigation.
On the redesigned Organization settings, both slots are on **General**: the **Wordmark** in the **Brand** section and the **Icon** in the **Identity** section.
If you have uploaded a full logo, it is used. If not, the square icon and your organization name are used together. The **Brand color** set there is what **Use brand color** applies.
<Frame>
<img alt="Email header showing organization logo and name" />
</Frame>
The same branding applies to the header of your vendor portals and intake pages, so a vendor who receives your email and clicks through to your portal sees one consistent identity.
<Note>
Org branding on emails and portals is released per organization. If your emails still show Coverbase branding and you would like your own applied, contact your Coverbase representative and they will enable it for you.
</Note>
This covers logo, color, and layout. To send that branded email from your own domain instead of `coverbase.ai`, see [White-labeling your vendor-facing domain](/user-guides/white-labeling).
## Who receives what
Each person controls their own notification delivery under **Account → Notifications** (choose your name in the top right, then **Account**, or **Settings** in the **Notifications** menu). Two things are separate there:
* **In-app** notifications always appear in the bell menu. They cannot be switched off, because that list is the record of what happened.
* **Email** is optional per notification type.
Some types are on by default and some are off, chosen to keep the default inbox useful rather than noisy. Anyone can change their own.
You can also choose **how** email arrives:
* **Immediate** sends each notification as it happens.
* **Digest** collects your unread notifications into one email a day, sent at the **Digest time** you pick (shown in your own time zone).
Even on digest, **Send urgent notifications immediately** lets SLA breaches, overdue reminders and direct mentions skip the digest and reach you right away.
## The notification catalog
These are the notifications your own team can receive. "Default" is the starting email setting for a new user; everyone can change their own.
### Assessments
| Notification | Sent when | Default |
| - | - | - |
| Assessment assigned | You are assigned to an assessment | Off |
| Assessment ready to view | An assessment you are watching is ready | On |
| Assessment control set ready to review | A control set you review is ready | On |
| Assessment control set review reminder | You have control sets still to review | On |
| Assessment control section review reminder | You have control sections still to review | On |
| Assessment control set follow-up completed | A follow-up finished and the evaluation re-ran | On |
| Assessment reminder | A vendor or service is due for reassessment | On |
| Stakeholder reminder for reassessment | Document collection for a reassessment is approaching | On |
| Overdue portal | A portal remains open past its due date | On |
### Findings and commitments
| Notification | Sent when | Default |
| - | - | - |
| Finding assigned | A finding is assigned to you | On |
| Finding status changed | A finding's status changes | Off |
| Finding risk changed | A finding's risk level changes | Off |
| Finding due reminder | A finding is overdue or approaching its due date | Off |
| Commitment created | A commitment is created | Off |
| Commitment status changed | A commitment's status changes | Off |
| Commitment due reminder | A commitment is overdue or approaching its due date | Off |
| Portal commitment submission | A vendor responds to a commitment through a portal | On |
| Finding risk acceptance expiring | A finding's accepted risk expires in a week | On |
| Finding risk acceptance expired | A finding's accepted risk expires and the finding reopens | On |
### Monitoring
| Notification | Sent when | Default |
| - | - | - |
| Radar detector alert | A detector raises an alert needing review | On |
| Continuous monitoring alert | A high-risk event is detected in your vendor ecosystem | On |
| Reassessment trigger fired | A trigger matched and proposed a draft reassessment | On |
| Case created | A new case is opened | On |
| Monitoring record verdict changed | The monitoring record of a vendor where you are a risk analyst changes verdict | On |
| Sanctions and watchlist matches | Screening raises a match against a vendor you are responsible for | On |
### Vendors and portals
| Notification | Sent when | Default |
| - | - | - |
| Vendor submits documents | A vendor submits documents through your portal | On |
| Vendor sends a portal message | A vendor writes a message on a portal request | On |
| Questionnaire submitted through portal | A questionnaire you watch is submitted | On |
| Intake draft ready for review | An intake request draft assigned to you has finished autofilling | On |
| Relationship owner assigned | You are made a relationship owner | Off |
| Bulk vendor document upload status | A bulk upload you started finishes | On |
| Document expiry reminder | A vendor document is about to expire or one of its dates falls due | On |
| Obligation extraction status | An obligation extraction you started finishes | On |
| SLA measurement due reminder | An SLA measurement is overdue or approaching | Off |
| Supplier bank change awaiting review | A supplier submits new bank details that need review | On |
| Supplier bank change decided | A supplier bank change is approved or rejected | On |
| Supplier update request outstanding | A supplier has not responded to an update request | On |
| Supplier certification expiring | A supplier's diversity certification is about to expire | Off |
| Supplier tax ID verification issue | A supplier's tax ID could not be confirmed with the issuing authority | Off |
### Mentions and work
| Notification | Sent when | Default |
| - | - | - |
| Note mentions | Someone mentions you in a note | On |
| Dismissal mentions | Someone mentions you in the reason for dismissing a Radar signal | On |
| User group mentions | A group you belong to is mentioned | On |
| User group assignments | A group you belong to is assigned something | On |
| Work queue item assigned | A work queue item is assigned to you | On |
### Exports and system
| Notification | Sent when | Default |
| - | - | - |
| Report ready for download | A report you requested is ready | On |
| Assessment report ready | An assessment report you exported is ready | On |
| Documents ready for bulk download | A bulk download you requested is ready | On |
| Dashboard scheduled exports | A dashboard export you scheduled runs. Turning it off pauses every schedule you own | On |
| Control set creation status | Control set creation finishes or fails | On |
| Email received | An email arrives for an assessment assigned to you | On |
| Email failed to deliver | An email, such as a portal invitation, bounces | On |
| Weekly digest | A weekly summary of activity in your organization | On |
### Contracts, risk and Inspect
| Notification | Sent when | Default |
| - | - | - |
| Contract date reminder | A contract is about to expire or renew, or reaches a notice, audit or review date | On |
| Contract expired | A contract you own or watch moves to its expiration status | On |
| Risk proposal awaiting review | The risk agent proposes a new risk, a re-score or a stale review in a domain you review | On |
| Risk outside appetite | A risk you own or review is re-scored above its domain's appetite | On |
| Inspection needs attention | An inspection you started stops and needs you to act, or fails | On |
| Inspection found an issue | An inspection you started or scheduled finds an issue with a control | On |
| Inspection found a material change | A drift inspection you started or scheduled finds a change to a control's evidence that matters | On |
<Frame>
<img alt="Weekly digest email" />
</Frame>
## Vendor-facing email
These go to people outside your organization and are not controlled by anyone's personal notification settings. They use the **External** layout.
| Email | Sent when |
| - | - |
| Portal invitation | You invite a vendor to a portal or questionnaire |
| Portal access link | A vendor requests a fresh sign-in link |
| Portal reminder | A portal is approaching or past its due date |
| Commitment reminder | A vendor has open commitments needing a response |
| Weekly vendor portal summary | A vendor has several outstanding portal requests |
| Follow-up questions | You add follow-up questions to a submission |
| Case follow-up | You reply on a case thread |
| W-9 reminder | A vendor's W-9 on file needs refreshing |
| Obligation note | You add a note to an obligation with an active portal |
| Portal passcode | A vendor asks for a one-time code to open a portal request |
The wording of portal invitations and follow-ups is yours to edit in the **Templates** list on **Configuration → Communications**, along with attachments. Sender identity is set at the top of the same page, and reminder cadence on the portal template under **Configuration → Portals**. See **Step 8** of the [Admin and setup guide](/user-guides/admin-setup).
## Contract and report email
| Email | Sent when |
| - | - |
| Contract reminders | A contract reaches its end, renewal, audit, action, notice, or termination-notice date |
| Scheduled dashboard export | A dashboard export you scheduled runs |
Contract reminders are configured per organization and can be turned off for a single contract without affecting the rest. See [Contract dates and reminders](/user-guides/contract-dates-and-reminders). Both emails also have a row in each person's notification settings. Turning off **Contract date reminder** stops that person receiving contract reminders. **Dashboard scheduled exports** works differently: turning it off pauses the schedules on every dashboard that person created, for every recipient, and it does not stop the email reaching someone who is only a recipient. See [Exporting and scheduling dashboards](/user-guides/dashboard-exports).
<Frame>
<img alt="Contract renewal reminder email" />
</Frame>
## Common questions
**An email went out looking wrong. What do I check first?**
Open **Configuration → Communications**, find **Layouts**, confirm which layout the affected side (**External (vendors)** or **Internal (team)**) is set to, and use **Send test to myself**. That delivers exactly what a recipient would get.
**Someone says they are not getting emails.**
Check their **Account → Notifications** page first, since the setting is per person. If they are on digest, the email is batched rather than missing. Also check whether the address has bounced: a hard bounce suppresses future sends, and whoever triggered the original email receives an "Email failed to deliver" notification.
**Can I turn off email for my whole organization?**
Not in one switch. Email is a per-person setting, so one person's preferences never change what a colleague receives.
**Our logo looks stretched or cropped.**
Check which slot it is in. The **Logo** slot (**Icon** on the redesigned settings) expects a square image and the **Full Logo** slot (**Wordmark**) expects a wide logotype. A wide logo in the square slot is the usual cause.
## Related
<CardGroup>
<Card title="White-labeling your vendor-facing domain" icon="globe" href="/user-guides/white-labeling">
Send vendor email from your own subdomain instead of coverbase.ai.
</Card>
<Card title="Admin and setup guide" icon="sliders" href="/user-guides/admin-setup#step-8-report-and-email-templates">
Step 8 covers the vendor email templates: sender identity, instructions, and reminder cadence.
</Card>
<Card title="Contract dates and reminders" icon="calendar-days" href="/user-guides/contract-dates-and-reminders">
Which contract dates send a reminder, and how to turn one off per contract.
</Card>
<Card title="Assignment, delegation and out of office" icon="user-clock" href="/user-guides/assignment-and-delegation">
How group assignments and mentions reach the people who are notified.
</Card>
</CardGroup>
# The engagement record
Source: https://docs.coverbase.com/user-guides/engagement-record
Follow an engagement from request to decision and exit: the tracker and expected decision date, your to-dos, Risk Group status, linking and reusing due diligence, the Risk Summary recommendation and decision, delivery, notices, and the corporate family.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers an engagement's page, its **Risk Summary** tab, and the **Lifecycle Routing and Reminders** settings under **Configuration → Communications**. It sits beside [Front Door triage](/user-guides/front-door-triage), which comes before it, and [Monitoring plans](/user-guides/monitoring-plans) and [Offboarding and continuity](/user-guides/offboarding-and-continuity), which come after. For what the module is, see [Engagement record and Risk Summary](/products/engagement-record).
</Info>
An engagement is one piece of business with a vendor. Its page tells the Transaction Owner, the person who asked for it, where it is and what is left, and gives them the Risk Summary to decide on. The TPRM Office uses the same page to see which Risk Groups are still working.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
The mistake people make most often is expecting a decision button before due diligence is finished. **Proceed to contracting** stays locked until every risk domain is complete or reused.
## Step 1: Name the TPRM Office and Supply Chain
Open **Configuration**, choose **Communications**, and find **Lifecycle Routing and Reminders**.
* **TPRM Office** is the user group told when due diligence goes out to a vendor and when it completes. It also approves offboarding.
* **Supply Chain** is the user group that files the executed contract and approves offboarding with the TPRM Office. Left unset, the TPRM Office approves offboarding alone.
* **Copy the TPRM Office**, **Copy relationship owners** and **Copy the requester** decide who a past-due vendor reminder copies. Until you save a setting here, past-due reminders go to the vendor only.
* **Risk Summary Open Tracking**, off by default, adds a tracking pixel to the Risk Summary email only, and records when each recipient first opens it. Other emails are never tracked. Turn it on only if your privacy policy allows it.
The Front Door has its own sign-off groups, set on **Configuration → Front Door**. See [Front Door triage](/user-guides/front-door-triage#step-1-configure-the-front-door).
## Step 2: Open the engagement
Open the vendor, choose the engagement, and read **Where This Request Is** at the top. The stages are **Request**, **Triage**, **Inherent risk**, **Due diligence**, **Decision**, **Contract**, **Active** and **Exit**, or **Not proceeding**. Coverbase works out the current stage from the record, and everyone involved sees the same tracker.
<Frame>
<img alt="Engagement page for Consumer analytics platform with the tracker at Decision, a Decide whether to proceed to-do, and eight Risk Groups, six complete and two reused" />
</Frame>
Once the contract is signed, **Active** reads **Live since** and the date. **Exit** comes after it:
* When someone files an offboarding request for the engagement, Exit becomes the current stage and reads **Exit under way**. The header badge reads **Exiting**.
* When the offboarding completes, Exit reads **Exited** and the date, and the header badge reads **Exited**.
* A canceled offboarding request takes the engagement back to Active.
An exiting engagement still counts as active in [Program Insights](/user-guides/program-insights) until its exit completes. An exited one leaves the program's figures. On the engagement list, the **Stage** filter includes **Exiting** and **Exited**.
<Frame>
<img alt="Where This Request Is tracker with every stage done and the Exit stage reading Exited Dec 29, 2024" />
</Frame>
**Expected decision** is when the last open domain review is due under its SLA. It is blank when any open review has no SLA target, and once a decision is recorded.
**Your To-Dos** lists what is waiting on you: a domain review assigned to you or your group, **Review the Risk Summary** (which arrives when every Risk Group finishes), or **Decide whether to proceed**.
## Step 3: Read the Risk Groups
**Risk Groups** shows each domain that needs a review, with its reviewer and status:
| Status | Meaning |
| - | - |
| **Complete** | Every performed assessment that needs this domain has finished its review. |
| **Reused** | A reused assessment's completed review covers it. The card names the source. |
| **In review** | A reviewer is working on it. |
| **Waiting on vendor** | The vendor still owes answers or evidence. |
| **Not started** | No review has begun. |
The summary line reads, for example, **3 of 5 complete · 1 reused**.
## Step 4: Link due diligence
**Due Diligence** lists the assessments that count toward the engagement and their review progress. To add one, click **Link assessment**, choose it, and decide whether to turn on **Reuse earlier diligence**: the assessment was performed for something else, and its completed reviews satisfy this engagement's domains without being repeated. Click **Link**.
* A Front Door reuse decision links the prior assessment as reused for you, and satisfies exactly the domains that decision marked for reuse.
* Linking a prior assessment as reused by hand picks up the vendor's latest decided reuse of it.
* Archived and canceled assessments drop out. **Unlink assessment** removes one.
## Step 5: Write the recommendation
<Frame>
<img alt="Risk Summary recommending Proceed with conditions, with a Risk by Domain table, one open issue, three conditions, and a Decision card offering Proceed to contracting and Don't proceed" />
</Frame>
On the **Risk Summary** tab, the TPRM Office clicks **Edit recommendation**, picks **Proceed**, **Proceed with conditions** or **Do not proceed**, writes the **Rationale**, and lists **Conditions**, one per line. Click **Save**.
The rest of the summary is read live from the linked assessments: **Risk by Domain** with **Inherent**, **Control Effectiveness**, **Residual** and **Basis** (reused domains name their source), the **Issues** raised, and **Built From**, which counts the assessments and issues behind it. While due diligence is still running, the summary says so and updates as each Risk Group finishes.
**Download PDF** prepares a PDF. You get a notification when it is ready.
## Step 6: Record the decision
When the last Risk Group signs off, the Risk Summary is sent to the Transaction Owner automatically. The Transaction Owner, or anyone who can update the vendor, then clicks **Proceed to contracting** or **Don't proceed**, with an optional note for the TPRM Office.
**Proceed to contracting** opens the contract handoff and notifies whoever its task is assigned to, unless a handoff is already pending or done. See [The contract handoff](/user-guides/offboarding-and-continuity#complete-the-contract-handoff).
The engagement's **Contract** tab shows the clause pack and linked contracts on the left. On the right, **CLM Sync** shows each contract's record in your contract lifecycle system (Ironclad or Icertis): its status there, when it was last received and pushed, when the executed copy was filed, and any open conflicts in the steward queue. **Contract Family** shows the parent agreement, the other agreements under it, and what the contract renews or is renewed by. **Execution Handoff** sits below them.
## Who is told what
| Notice | When | Who |
| - | - | - |
| Due diligence launched | Once per performed assessment, when its portal invitation goes out | The Transaction Owner and the TPRM Office |
| Due diligence complete | The first time every domain is complete or reused | The TPRM Office and the Risk Groups |
| Risk Summary ready | At the same moment | The Transaction Owner |
Both completion notices list the domains satisfied by reused diligence. If a review reopens before anyone decided, the completion is cleared and sent again when it completes. After a decision, it is not.
The **Transaction Owner** is the engagement's relationship owners (people and groups), plus whoever raised the intake request a linked assessment came from. An engagement with no owners of its own uses the vendor's.
## Delivery
**Delivery** on the Risk Summary shows, for each recipient, **Sent**, **In their notifications**, **Seen** or **Read in app** with dates, and **Emailed** with the time the email went out.
With **Risk Summary Open Tracking** on (step 1), it also shows **Email opened** with the date of the first open, or **Email not opened yet**. The card says whether tracking is on. An open is an image load: a mail client that blocks images never reports one, and a security scanner can report one before anyone read the email, so **Read in app** is the stronger fact.
## The corporate family
On the vendor's page, **Corporate Family** shows the vendor's parent and subsidiaries. Click **Set parent company**, choose the parent vendor and **Save**. The family's rating, contract value and engagements roll up to the ultimate parent. **Remove parent** detaches it.
Vendors and engagements can also carry a **Business Unit**, which the reviewer matrix and dashboards use.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| **Opens when due diligence is complete.** instead of the decision buttons | A risk domain is still not complete or reused. | Check **Risk Groups** for the domain still open. |
| **Link an assessment to start due diligence.** | No assessment is linked. | Click **Link assessment**. |
| The tracker reads **Exit under way** | The engagement has an open offboarding request. | Work the exit plan on the **Exit** tab, or cancel the request. |
| No expected decision date | An open review has no SLA target, or a decision is already recorded. | Set SLA targets on your risk domains. |
| A domain shows **Not started** although a reused assessment covers it | The reuse decision marked the domain for an abbreviated review or new due diligence, not reuse. | Expected. Only domains marked for reuse are satisfied. |
| The TPRM Office got no notices | No TPRM Office group is set. | Set it under **Lifecycle Routing and Reminders**. |
| The **CLM Sync** card says the contract is not synced yet | Your contract lifecycle system is connected, but this contract has not been sent to it or received from it. | Wait for the next sync, or open the connection from the card. |
| **Proceed to contracting** did not open a new handoff | A handoff is already pending or done for this engagement. | Open the **Contract** tab. |
| A past-due reminder copied nobody internal | The lifecycle settings were never saved. | Change a setting under **Lifecycle Routing and Reminders** to save them. |
## Related
<CardGroup>
<Card title="Front Door triage" icon="door-open" href="/user-guides/front-door-triage">
Where reuse is decided.
</Card>
<Card title="Monitoring plans" icon="calendar-check" href="/user-guides/monitoring-plans">
What the engagement owes once active.
</Card>
<Card title="Offboarding and continuity" icon="right-from-bracket" href="/user-guides/offboarding-and-continuity">
The contract handoff and the exit.
</Card>
<Card title="The vendor record" icon="building" href="/user-guides/vendor-record">
Vendors, services and engagements.
</Card>
</CardGroup>
# Evidence quality and source credibility
Source: https://docs.coverbase.com/user-guides/evidence-quality
How Coverbase grades the credibility of web evidence, where you set the minimum bar, and how that changes what the AI is allowed to cite in an assessment.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the credibility bar applied to web evidence. Where you set it lives in the [Admin and setup guide](/user-guides/admin-setup), and what you do with the result lives in the [Analyst and reviewer guide](/user-guides/analyst-reviewer).
</Info>
When a control cannot be answered from the documents a vendor gave you, Coverbase looks at the public web. That is useful on thin evidence, and it is also a risk: a page with no author and no organization behind it should not sit in your audit file next to a SOC 2 report.
Source credibility is the control for that. Every web page Coverbase pulls in during an assessment is graded for **publisher accountability** before it is allowed to become evidence, and you set the minimum grade a page must reach. Pages below your bar are discarded before the evaluating AI ever sees them.
## The short version
<CardGroup>
<Card title="Grade" icon="award">
Every candidate web page gets one of three grades: **Unreliable**, **Reputable**, or **Authoritative**.
</Card>
<Card title="Filter" icon="filter">
You set a **Minimum credibility** per web-search evidence source. Anything below it is dropped, not down-weighted.
</Card>
<Card title="Show your work" icon="receipt">
The surviving grade and the reason for it are recorded on the citation, visible in the evidence card and exportable to Excel.
</Card>
</CardGroup>
<Note>
The grade measures **who is accountable for the material**, not whether the page is useful. Relevance is judged separately. A page can be highly relevant and still be discarded for having no accountable publisher, and it can be Authoritative and still be dropped as irrelevant to the control.
</Note>
## The credibility scale
The three grades are ordered, and the setting is a floor: choosing **Reputable** accepts Reputable and Authoritative.
| Grade | What it means | Typical examples |
| - | - | - |
| **Unreliable** | No identifiable publisher who is answerable for being wrong. No named author, no sourcing, no organization standing behind the claim. | Unattributed blogs, AI-generated content farms, scraped listicles, sites that exist to capture search traffic |
| **Reputable** | An identifiable publisher with editorial, professional, or commercial accountability, but not acting as the official or attesting authority for this material. | Established press, a vendor's own engineering or marketing pages, analyst profiles, derived ratings, directories, aggregators |
| **Authoritative** | The publisher is acting as the official or attesting authority for this material and carries a formal, content-specific duty of accuracy. | Regulators, standards bodies, an accredited auditor issuing an attestation, the vendor's own official disclosures and filings |
### What the grade deliberately does not measure
These exclusions keep the scale stable, and they are worth explaining to a reviewer or an auditor:
* **Not page quality or completeness.** A thin page from an accountable publisher is still Reputable. A polished page from nobody is still Unreliable.
* **Not primary versus secondary.** A well-sourced news report about a breach is Reputable, not Authoritative, because the outlet is not the attesting authority, but it is not penalized for being secondary either.
* **Not the document kind.** A PDF does not outrank an HTML page.
* **Not usefulness to the control.** That is relevance, judged separately and applied separately.
* **Not the hosting platform.** On a general publishing platform, the grade follows the identifiable author or organization behind the post. The platform's own reputation neither raises nor lowers it.
<AccordionGroup>
<Accordion title="How the vendor's own pages are graded" icon="building">
First-party pages go through the same scale, and always have an accountable publisher, so they are never Unreliable. The vendor's official disclosures, filings, and attestation pages grade **Authoritative**. Its marketing, engineering, and careers pages grade **Reputable**. Any of them can still be dropped as irrelevant to the control.
</Accordion>
<Accordion title="How search-bait pages are handled" icon="magnifying-glass">
Purpose is used only as a tiebreaker, and only at the Unreliable/Reputable boundary: when accountability is ambiguous, a page that exists to capture search traffic rather than to inform weighs toward Unreliable. Purpose never affects the Reputable/Authoritative boundary.
</Accordion>
</AccordionGroup>
## Where you set the bar
**Minimum credibility** lives on each **Web search** evidence source, next to that source's instructions and its **Required** checkbox. It appears only on web-search sources, because it only governs web evidence.
The dropdown shows three options, each with its definition inline:
| Option | Stored value | Effect |
| - | - | - |
| **No minimum** | `unreliable` | The default. Nothing is filtered on credibility. Pages are still graded and the grade is still recorded. |
| **Reputable** | `reputable` | Drops pages with no accountable publisher. |
| **Authoritative** | `authoritative` | Only official and attesting publishers survive. |
### Set-level and control-level
You configure evidence sources in two places, and the relationship between them matters:
1. **Control set → Evidence sources.** The default for every control in that set. Set this once and your whole framework inherits it.
2. **Individual control → Evidence sources.** A control inherits the set's sources until you click **Customize sources**, which starts from a copy of the set's list. From then on the control's sources **fully replace** the set's, including the credibility bar. A control-level source list is not merged with the set's, so if you override a control, check the minimum there. **Use control set sources** returns the control to inheriting.
<Tip>
Configure at the set level first and override individual controls only where the evidence bar differs. It is easier to defend "this framework requires Reputable, these four attestation controls require Authoritative" than a per-control patchwork.
</Tip>
<Warning>
Because a control-level evidence source replaces the set's entirely, a control you overrode before you tuned the set's credibility bar will keep whatever minimum was saved on it. If you tighten a control set and want it to apply everywhere, check the controls that carry their own sources.
</Warning>
## What happens during an assessment
Grading is not a separate scan you wait on. It runs inside the retrieval that already happens for each control:
<Steps>
<Step title="Queries are generated">
Coverbase builds web queries from the control text, its guidance, and any web-search instructions you wrote on the evidence source.
</Step>
<Step title="Candidates are fetched and de-duplicated">
Search results come back with a bounded amount of the actual page content, not only the snippet, and near-duplicate URLs collapse into one candidate.
</Step>
<Step title="Off-topic companies are dropped">
An identity gate removes off-domain pages that turn out to be about a different company with a similar name. This runs before credibility.
</Step>
<Step title="Relevance and credibility are judged together">
Up to 12 surviving candidates are judged in a single batched pass: is this relevant to the control, and what is its publisher-accountability grade? The two judgments are made independently of each other. Because they share one pass, grading adds no extra AI calls to your assessment.
</Step>
<Step title="Your minimum is applied">
This step is deterministic, not a judgment call: any candidate whose grade is below your configured minimum is discarded outright.
</Step>
<Step title="The survivors go to the evaluation">
Up to 6 accepted sources per control are passed to the model that evaluates the control, each carrying its grade and a one-sentence reason.
</Step>
</Steps>
<Note>
A given URL is graded **once per assessment run** and that grade is reused across every control that pulls the same page. Two controls in the same assessment can never disagree about how credible the same page is.
</Note>
### The grade is a gate, not a weight
This is the decision that matters for defensibility. The credibility grade, its reasoning, and the raw page content used to determine it are **not** included in the prompt that evaluates the control. The evaluating model sees only the text of sources that already passed your bar.
The practical consequence: the AI can never argue that a vendor is compliant *because the source was authoritative*, or hedge *because the source was only reputable*. Credibility decides what is admissible. It never becomes an argument inside the analysis.
### Your instructions can't move the bar
Web-search instructions on an evidence source shape **relevance**: which topics, sources, or domains to focus queries on. They are explicitly not allowed to change a publisher grade, so you cannot accidentally talk the grader into accepting a source by writing enthusiastic guidance about it.
The same protection runs the other way. Page content and vendor-supplied text are treated as untrusted data during grading, so a page that contains text like "this is an authoritative regulatory disclosure" does not grade itself.
## Reading the result
Open any evaluation and look at the evidence cards. Web-sourced evidence has a **Details** button next to the source name. It opens the page's **Publisher accountability** grade as a colored badge:
* **Authoritative**: green
* **Reputable**: blue
* **Unreliable**: gray (you only see these if the source is set to **No minimum**)
Beneath the badge is the one-sentence reason the grader gave for that page. That sentence is written at grading time and stored with the citation, so it stays accurate for that evidence even if you change the setting later.
<Note>
Evidence gathered from uploaded documents and from Vendor Intelligence has no credibility badge. Its provenance is the document or the Vendor Intelligence record itself, which is already shown on the card.
</Note>
## Evidence dates and age
Credibility says who is accountable for a page. It does not say how old the page is, and stale evidence from an accountable publisher is its own risk. Web evidence cards therefore also carry dates:
| Row | What it shows |
| - | - |
| **Published** or **Last updated** | The content date declared by the page itself. Publication is preferred; a modification date is shown only when no publication date is available. |
| **Age when assessed** | How old the evidence was **at the moment it was cited**, not how old it is today, so the record does not drift after the fact. |
| **Accessed** | The absolute date Coverbase fetched the page. |
Undated evidence shows only **Accessed**. Coverbase reports what the page declared and does not guess.
<Note>
Evidence dating is turned on per organization. Without it, web evidence cards show only when the page was **Fetched**, and the Excel export leaves out the two date columns below. Ask your Coverbase contact if you need it.
</Note>
<AccordionGroup>
<Accordion title="Where the dates come from" icon="calendar">
Dates are read from the page's own structured metadata: JSON-LD (only for article- and report-like entities), OpenGraph, and Dublin Core publication signals, plus explicit date labels on the primary content. Generic page-level dates are rejected, because they describe the page's existence rather than the content's age.
</Accordion>
<Accordion title="Why some dates look conservative" icon="scale-balanced">
An HTTP `Last-Modified` header is never treated as a content date, because a CDN touch would silently make old evidence look fresh. Dates in the future are rejected outright. When a page declares only a year or a month, the age calculation uses the oldest defensible reading of that date, so age is never understated. Conflicts between signals resolve conservatively.
</Accordion>
<Accordion title="Do dates affect what gets used?" icon="circle-info">
No. Date enrichment runs **after** evidence selection. It never influences retrieval, credibility grading, or filtering; it only annotates what was already accepted. If a page's dates cannot be determined, the evidence is still used and the date rows do not appear.
</Accordion>
</AccordionGroup>
## Exporting the record
Export an assessment as **Excel** with evidence included, and the Evidence sheet carries the provenance columns alongside each citation:
| Column | Contents |
| - | - |
| **Source credibility** | The grade recorded on that citation |
| **Evidence Date** | The published or last-updated date, where the page declared one |
| **Evidence Age When Assessed (Days)** | A plain number, so you can sort, threshold, or chart it |
For each cited page a reviewer can see who published it, what standard of accountability it met, how old it was when it was used, and when you fetched it.
<Tip>
Age is exported as a number of days so you can filter on it. Sorting the Evidence sheet by that column is the fastest way to find controls resting on old web evidence that is worth refreshing.
</Tip>
## Choosing a threshold
New web-search sources start at **No minimum**. **Reputable** is the right answer for most of a framework, so set it deliberately, and reserve the extremes for the controls that earn them.
| Set it to | For controls like | Why |
| - | - | - |
| **Authoritative** | Certification and attestation status, regulatory actions and enforcement, breach-notification filings, sub-processor and disclosure obligations | These turn on formal status. If the regulator, the auditor, or the vendor's own disclosure does not say it, you do not want it in the file. |
| **Reputable** | Security practices, operational posture, incident history, staffing and organizational maturity, most of everything else | You want real-world signal from accountable publishers, not only the vendor's official line. |
| **No minimum** | Exploratory or discovery-oriented controls where you would rather see everything and judge it yourself | Nothing is filtered, but everything is still graded and badged, so you can see what you are looking at. |
<Warning>
Raising a control to **Authoritative** will reduce how much web evidence it finds, sometimes to nothing. That is the intended trade: the control is more likely to come back needing vendor evidence or human review rather than resting on secondary reporting. Expect more follow-ups, not fewer.
</Warning>
## Changing the setting later
The minimum applies **at the moment retrieval runs**. Changing it does not retroactively re-filter assessments that have already been evaluated, and it does not rewrite grades already recorded on past citations. Those stay as a record of what the bar was when the work was done.
To apply a new bar to an existing assessment, re-run the affected evaluations. Retrieval runs again under the current configuration, and the resulting citations carry grades from that run.
## When grading can't run
If the grading pass fails (a model or provider error mid-assessment), Coverbase never invents a grade:
* With a minimum of **Reputable** or **Authoritative**, no web evidence is used for that control. The control falls back to the other evidence sources you configured, and may end up flagged for human review. An ungraded page must not slip past a bar you set.
* With **No minimum**, a fallback set of results from the vendor's own domain may still be used, and those citations carry no badge, because no grade was ever established.
The failure is recorded either way, so the gap is visible rather than silent.
## What this covers, and what it doesn't
Source credibility governs **web evidence gathered while evaluating controls in an assessment**. The edges matter when you are answering a customer or an auditor:
| Area | Credibility grading and filtering |
| - | - |
| **Assessment control evaluation (web search)** | Yes: graded, filtered against your minimum, badged, and exported. |
| **Uploaded vendor documents** | No. A document's provenance is the document and its source, shown on the evidence card. Publisher-accountability grading does not apply. |
| **Vendor Intelligence** | No. Vendor Intelligence is a separate evidence source, built from vendor enrichment. It carries no credibility bar of its own. |
| **Intake and pre-qualification research** | No. Intake's web lookups inform vendor matching and qualification; they do not produce cited control evidence, so this scale is not applied. |
| **Supplier Radar monitoring** | No. Radar draws on a curated feed catalog instead. See the [Source library](/products/source-library) and [Detector library](/products/detector-library). |
<Note>
If you need the bar extended to one of the areas above, tell us which control decisions depend on it. The scale itself is source-agnostic; the enforcement point is what is currently scoped to assessment evaluation.
</Note>
## Frequently asked questions
<AccordionGroup>
<Accordion title="Does raising the bar make the AI stricter about compliance?" icon="circle-question">
No. It makes the AI **more selective about what it reads**, not harsher about what it concludes. **Evaluation Strictness** is a separate setting on the control set, from **Accepting** to **Exacting**. Credibility changes the inputs; strictness changes the judgment.
</Accordion>
<Accordion title="Will Authoritative-only stop the AI hallucinating?" icon="circle-question">
It removes a specific and real failure mode (unattributed and machine-generated pages supporting a load-bearing claim), but it is not a general hallucination control. Every conclusion still traces to a citation you can open, and Correct the AI remains the mechanism for fixing a judgment that reads its sources wrongly.
</Accordion>
<Accordion title="Can I see what was rejected?" icon="circle-question">
Rejected candidates are not surfaced in the UI; the evidence card is a record of what was used. Rejections are captured in Coverbase's internal logs, so support can reconstruct why a specific page did not make it into an assessment if you need that for an investigation.
</Accordion>
<Accordion title="Does grading slow assessments down or cost extra?" icon="circle-question">
Grading rides along in the relevance pass that already ran, so it adds no additional AI calls per control. Date enrichment runs after evidence selection on a bounded, best-effort budget and is skipped rather than allowed to hold up an assessment.
</Accordion>
<Accordion title="One page, two controls: can the grades disagree?" icon="circle-question">
No. Within an assessment run a URL is graded once and that grade is reused everywhere it appears. Relevance can and should differ between controls; credibility cannot.
</Accordion>
<Accordion title="Can I set the minimum through the API?" icon="circle-question">
Yes. Evidence sources carry a `minimum_credibility` field (`unreliable`, `reputable`, or `authoritative`, defaulting to `unreliable`) on both control sets and individual controls, so you can manage the bar as configuration alongside the rest of your control-set definition.
</Accordion>
</AccordionGroup>
## Related guides
<CardGroup>
<Card title="Admin and setup guide" icon="sliders" href="/user-guides/admin-setup">
Where evidence sources, strictness, and the rest of the per-set configuration live.
</Card>
<Card title="Analyst and reviewer guide" icon="user-check" href="/user-guides/analyst-reviewer">
Reviewing what the AI found, correcting it, and exporting the result.
</Card>
<Card title="How to run an assessment" icon="list-check" href="/user-guides/running-an-assessment">
The full assessment lifecycle, including the five ways evidence gets collected.
</Card>
<Card title="Assessment Copilot" icon="clipboard-check" href="/products/assessment-copilot">
The evaluation engine these settings configure.
</Card>
</CardGroup>
# Financial health guide
Source: https://docs.coverbase.com/user-guides/financial-health-score
How to read a vendor's Financial Health Score, what the confidence tier tells you, and how private companies with no filings are scored.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For what the capability is and where it stops, see [Financial Health Score](/products/financial-health-score).
</Info>
This page scores how likely a vendor is to still be trading, and to still be investing in the product you depend on. It is built from filings, funding, corporate standing and public signals, without asking the vendor anything.
## Finding it
Open a vendor, go to **Vendor Intelligence**, and pick the **Financial** tab. The page opens under the title **Financial health**.
<Frame>
<img alt="The Financial health tab for a vendor, with Refresh, Upload financial statements, Export and the actions menu at the top. The Financial Health Score of 64, Medium Risk, sits on its scale with the confidence tier, the peer benchmark, and the runway with the stability class. The summary lists what is in good shape, key gaps and checks still open. Below it, collapsed rows read How the Score Is Built, Peers, Financial Figures, Events Affecting the Score, Sources and Documents and Your Team's Revisions, each with a one-line summary, and an On this page list sits to the right." />
</Frame>
## Reading the page
The page answers first and puts the evidence one click away.
1. **The verdict.** When your organization has a credit policy, the page leads with the vendor's **financial stability rating** under your methodology. The Financial Health Score, the peer benchmark and the runway sit in a row under it. Without a credit policy, the score leads.
2. **The summary.** What is in good shape, the key gaps, and the checks still open.
3. **The evidence rows.** Each row has a title and one line that says what is inside, such as the rating and how many items were rated, or how many follow-up questions a source answered. Click a row to open it. A row only appears when it has something in it.
The rows are **Credit Policy Rating**, **How the Score Is Built**, **Peers**, **Financial Figures**, **Submitted Statements**, **Events Affecting the Score**, **Credit Follow-up Questions**, **Sources and Documents**, and **Your Team's Revisions**. On a wide screen, **On this page** lists them beside the rows. Clicking a name there opens that row and scrolls to it.
The buttons at the top read, left to right, **Refresh**, **Upload financial statements**, **Export** and the actions menu (**...**). Hover over **Refresh** to see when the page was last refreshed and who or what started it. Downloads sit under **Export**: the PDF report, an Excel workbook, and the analytics workbook once your organization has analysed the vendor's statements. When the window is too narrow, **Upload financial statements** and the **Export** downloads move into the actions menu.
## The summary under the verdict
A short summary sits under the verdict. **What's in good shape** lists the strong pillars and any positive events, such as a funding round. **Key gaps** lists weak pillars and the adverse events that count. **Checks still open** lists events still awaiting review, and says so when the score rests on signals alone.
<Frame>
<img alt="The Financial health report for a vendor. The verdict leads with a financial stability rating of Moderate risk, then the score of 64 with its peer benchmark and runway. Under it, What's in good shape lists capital position scoring 71, momentum 76, corporate standing 92 and a major raise in August 2024. Key gaps lists a mass layoff in April 2026. Checks still open lists a CFO departure in May 2026." />
</Frame>
## Revising the page
Adverse events come from public reporting. Some are about a different company with a similar name, or did not happen as reported. **Revise from notes or evidence**, in the actions menu, corrects the page from text you paste.
1. Paste analyst notes, evidence the vendor sent, or a plain correction, and click **Propose changes**.
2. Review each proposed change: the event, why it should be dismissed, and the words from your text it rests on. Untick any you do not want. The preview shows the score and band the changes you keep would leave.
3. Click **Apply**, which counts the changes you kept (for example, **Apply 1 change**). The page is saved as a new version and marked **Analyst revised**.
On this page you can dismiss an adverse event. The score is recomputed from the pillar the event sat in. When the dismissed event drove an override, such as a bankruptcy filing or a going-concern opinion, the score stands as researched and the preview says so.
To have Coverbase do this check for you, pick **Check against the vendor's own pages** from the same menu. It reads the vendor's own website and the public record behind each item. An adverse event it can show is about a different company, quoting the page or record that shows it, is dismissed as a new version labeled **Automated review**. Read it and restore the previous version if you disagree. The same check runs on its own after every Zero Touch run.
A revision applies to your organization only. Other organizations see the research as it ran. When the research is refreshed, your accepted changes are carried onto it, and a change whose event no longer appears falls away. **Your Team's Revisions**, the last row on the page, lists every change and version, and **Restore** makes an earlier version current again.
## The summary at the top
The verdict answers three questions before any evidence: what the score was built on, how much that evidence is worth, and how stable the company is.
The runway verdict and the stability class sit beside the score. Where a model summary is available, a plain-language read of this specific vendor follows. It is marked as AI-generated and is written only from the evidence listed further down the page. The last line names the evidence basis and how many sources and signals went in.
When too little of the model could be scored, the number is drawn faded and a highlighted note says to read it as unmeasured. The scale under the score uses the score's own risk bands, from **Very high** to **Very low**.
On a vendor you have never looked at, the summary is usually enough on its own.
## Your credit policy rating
When your organization has set a financial methodology, **Credit Policy Rating** applies it to the vendor's latest full-year financials. The bands are your credit policy and rate the vendor for your organization only.
Each item shows its value, your bands for it, the rating it landed in, and how it ranks against its industry. **How the rating was reached** then walks the steps in order: combining the rated items, applying the sector profile, weighing considerations such as revenue trend and investor backing, and checking the audit requirement. Considerations move the rating one notch at most, and improving it takes two of them.
To change the bands, click **Edit methodology**.
When there are no statements to rate, the page says so under the rows. Upload the vendor's statements to rate it.
## How the score was reached
Open **How the Score Is Built**. The chart at the top of the row, titled **How 64 Was Reached** for the vendor pictured, walks from the arithmetic to the published figure: the **Measured pillars**, the **Model grade blend**, any guardrail or override, and the **Published score**.
The model grade is a judgement over the same evidence the page lists. The line under the chart says how much of the score it carries: more for a vendor with less evidence, up to half the score at Tier C, and it can never move the score by more than 20 points. A stability guardrail or a hard override still applies after it.
## The tier tells you what the number is worth
A 72 backed by audited filings and a 72 inferred from funding rounds and headcount signals are not the same claim. The confidence tier tells you which you are looking at. Mention it whenever a score surprises you.
Tier reflects what data was available, not how the vendor is doing. A private company with no filing obligation lands in a lower tier because of its jurisdiction and structure, not because anything is wrong.
<Note>
Scores used to be comparable only within a tier. They are now held to a common scale across tiers by the stability class below, so ranking a portfolio on the raw number is reasonable. The tier still tells you how much evidence stands behind any individual result.
</Note>
## How stable is this company
Companies do not all survive the same way, so one number cannot order them unless something says what kind of company each one is. The **stability class** does that, from what can be observed: scale, operating history, whether the business generates cash, and how dependent it is on outside capital. Never from a name or a ticker.
| Class | What it means |
| - | - |
| **Entrenched incumbent** | Files audited statements, very large, long-established, generates cash. |
| **Established operator** | Real revenue or headcount, years of history, and covers its own costs. |
| **Funded scale-up** | Past the fragility of a small team, still funded rather than self-sustaining. |
| **Early-stage, capital-dependent** | Small or young, and dependent on the next raise. |
| **Distress signals present** | Insolvency, closure, or cash running out. |
Each class occupies its own score range, and the ranges are ordered so that an early-stage company cannot out-rank an established one on inference alone. That is what stops a startup that raised last quarter from scoring above a profitable incumbent whose ratios are merely typical.
Two things the class does **not** do. It does not override evidence: a bankruptcy filing or a going-concern opinion drives the score straight through any floor. And it is not a judgement about quality, since an early-stage vendor may be an excellent supplier. It only describes what would happen if their funding stopped.
## Runway and burn for private companies
For a vendor that files nothing, the page estimates how long its cash lasts.
Nobody outside the company knows the real figure. The aim is not to guess it but to bound it well enough to separate a vendor with two years of cover from one with two quarters. That is the difference that matters over a contract term.
The estimate is built from what can be observed:
<Steps>
<Step title="Burn is derived from headcount">
Fully-loaded cost per employee is the operating figure that behaves most predictably across software companies, and headcount is the input most often available. Personnel is grossed up to a total operating cost, and the per-head figure is adjusted for the company's stage.
</Step>
<Step title="Revenue is netted off at gross margin">
A dollar of revenue does not fund a dollar of burn. Where no revenue figure is available, a conservative estimate for the company's stage stands in.
</Step>
<Step title="Capital is the last round, less what has been spent since">
Companies raise before they are empty, so the round is credited with a reserve on top, and consumption is charged from the date of the raise.
</Step>
<Step title="A round with no date is treated as half spent">
Most sources report the size of a private round but not when it closed. Assuming it closed yesterday would flatter every vendor, and assuming a fixed number of months would penalize the ones with a large payroll. Observing a company at an unknown point in its funding cycle means observing it, on average, halfway through, so half the round is treated as already spent.
</Step>
</Steps>
You will see a **range**, not a single number. Treat the low end as the planning figure.
Two related readings appear alongside it. **Self-sustaining** means revenue covers burn, so no cliff applies to that company. **Capital efficiency** is revenue per dollar raised, which separates a disciplined business from one that has bought its growth.
<Warning>
These are estimates, and they are labeled as such. Use them to rank and to prompt a question, not as a figure to quote back to the vendor.
</Warning>
## Where funding and headcount come from when there is no data subscription
Most private vendors are not in any paid financial database you have licensed, and the ones that are may not be covered. The page also reads the funding round, round type, employee count and founding year that Coverbase's own enrichment researched from public sources for that vendor, and feeds them into the runway model above.
Those figures are cited as **Web research** in the sources list, and they never raise the vendor's confidence tier, because a search result is not a filing however precise it looks. What they do is give a page that previously said nothing a cost base, a cash position and a stability class.
Where a licensed provider does answer, its figure wins. Web research only fills the gaps.
## When almost nothing resolved
A vendor with only one or two signals is capped at the middle of the scale, and the page says so under **Caps, Floors and Guardrails**.
The reason is that most of a score built on nothing comes from the adverse-events pillar finding nothing, which for a company nobody publishes anything about is an absence rather than a finding. A thin scorecard can report what it found, but it should not read as reassurance.
## What each pillar covers
The score rolls up several pillars, listed under **What Drives the Score** in **How the Score Is Built** with the inputs behind each one.
Read the pillars before the total when the score is doing something surprising. A drop driven by corporate standing is a different conversation from a drop driven by growth signals, and only one of them is urgent.
An empty adverse-events pillar is worth understanding. For a company whose filings we read, no events means nothing was disclosed. For a private company, it means nothing was observed, since our event coverage there is limited, so a clean slate is scored well but not perfectly.
## Score over time
The score history is in **How the Score Is Built**, after the pillars.
Each point is a restatement of the whole scorecard, not a daily reading. Shaded zones mark the risk bands.
Watch for a step that coincides with a change of confidence tier. That is us getting better data about the vendor rather than the vendor changing, and the chart says so when it happens.
## The financial vitals
Open **Financial Figures**. When the vendor files statements, the figures read from its annual report come first, then the vitals: the measured figures behind the score, grouped the way a credit reviewer reads them: scale and growth, profitability and cash, liquidity and leverage, capital and ownership, corporate standing.
Fields no source reported are left out rather than shown as zero. For a private company, "not reported" and "zero" are different facts, and the page will not conflate them.
## Industry comparison
**Peers** places the vendor beside the companies that sell what it sells, rated with your methodology. They are the same peers as the Security posture page.
The row shows how the peers' ratings split, how the vendor's current ratio and debt to worth compare with the peer median, a table of every company's ratios and rating, and where each company sits in your bands. A company with no statements shows its Financial Health Score and stays out of the medians.
## Peer benchmarks
The **Peer benchmark** in the verdict, and the detail in **Peers**, place the vendor against companies of comparable industry and size. The cohort is named, along with how many companies are in it.
If the page says a fallback cohort was used, the vendor's own industry had too few scored peers and the percentile is against a broader set than the label suggests. Read it as directional.
## Adverse events
Dated, sourced events that moved the score, each with a link to what reported it. Severity decays with age, so an old event counts for less than a recent one of the same kind.
Events awaiting review are shown but do not move the number. An event your team dismissed through a revision stops counting for your organization only.
## Comparability adjustments
When a stability floor or ceiling changed the score, the page says so under **Caps, Floors and Guardrails** in **How the Score Is Built**, with the reason and the before-and-after figures.
A vendor floored at its class minimum and a vendor that earned the same number on its own signals are different situations, and a corrected score that looked like a computed one would hide that.
## Where the numbers came from
Open **Sources and Documents**. It lists every source behind the score with the date it was last seen, links out where a register publishes a stable per-company page, and the sources that were asked for and did not answer.
A cap or floor applied by a hard rule, such as a bankruptcy filing, is listed with its reason under **Caps, Floors and Guardrails**.
The documents your organization uploaded for the analysis are listed in the same row. Remove one there, or click **Regenerate** when the set has changed since the figures were computed.
## Where it shows up elsewhere
The score feeds the Financial health component of a [Zero Touch Score](/user-guides/zero-touch-assessments), carrying its tier through as the component's qualifier.
If a vendor has no Financial Health Score, the Zero Touch component is left out of the composite rather than scored as zero. A vendor with no filed financials has not failed the component; it has no component.
## Troubleshooting
| Symptom | Fix |
| - | - |
| Not yet scored | The vendor has not been resolved to a filer or a registry record yet. Check the Registrations tab first, since identifiers are how a vendor is matched to filings. |
| The score looks high for a company you know is struggling | Check the stability class and the runway. A funded early-stage vendor is capped, but "no bad news reported" still counts for something on a company nobody reports on. |
| Two vendors you would rank differently have the same score | Check whether a comparability adjustment fired on either. A vendor sitting at its class floor did not earn that number on its own signals. |
| The runway figure looks wrong | It is modeled from headcount and funding, not reported. The page lists the assumptions behind it, and the range matters more than the midpoint. |
| Revenue or headcount look wrong | Both are estimates at lower tiers. The vitals list names the source for each figure. |
| An adverse event is about a different company | Revise the page and paste why. Dismissing the event changes the score for your organization only. |
| The score changed with no news | Filings and funding data refresh on their own schedule. The scorecard records when each input was last seen. |
| You hold the vendor's own statements | Click **Upload financial statements** at the top of the page, or pick it from the actions menu (**...**) when the window is narrow. The score is rebuilt on them for your organization only. See [Financial Health Score](/products/financial-health-score#submitting-a-vendors-own-financial-statements). |
| The page describes a different company | Open the actions menu (**...**), pick **Correct the AI**, choose **This is a different company**, and say why under **What should the model know?**. Give the right website or registered legal name if you know it. |
## Related
<CardGroup>
<Card title="Global financial coverage" icon="earth-americas" href="/user-guides/global-financial-coverage">
The markets Coverbase reads filed statements from.
</Card>
<Card title="Security intelligence guide" icon="shield-halved" href="/user-guides/security-intelligence">
The other outside-in score on the same vendor.
</Card>
<Card title="Corporate registrations guide" icon="building-columns" href="/user-guides/corporate-registrations">
How a vendor is resolved to its filings.
</Card>
</CardGroup>
# Findings and remediation
Source: https://docs.coverbase.com/user-guides/findings-and-remediation
What happens after a finding exists: reading the Findings page, moving a finding through its statuses, asking a vendor for a commitment, verifying the work, and where findings show up in the rest of Coverbase.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It starts where a finding already exists. For turning an assessment issue into a finding, see [Work the issues](/user-guides/running-an-assessment#part-5-work-the-issues) and [Dispositioning issues](/user-guides/analyst-reviewer#dispositioning-issues). For what the module is, see [Findings Manager](/products/findings-manager).
</Info>
<Note>
Findings is an optional module. If you do not see **Findings** in the left navigation, ask your Coverbase representative to turn it on.
</Note>
A finding is a problem you have decided to track: a control the vendor failed, a clause that deviates from your standard, a Radar signal that turned out to be real. It carries an owner, a due date, a status, and a link back to whatever raised it. The finding is yours. It outlives the assessment it came from.
A commitment is the vendor's side of the same problem. It is a request you send through the vendor portal ("encrypt backups by 30 June"), which the vendor accepts, negotiates, declines, or completes. A finding can have several commitments, and the finding's status follows them.
The mistake people make most is treating the finding status as a free field. Once a finding has commitments, Coverbase sets its status from them. Setting it by hand works, but the next vendor response resets it. Work the commitment, and the finding follows.
## Where findings live
Click **Findings** in the left navigation. The page has three tabs across the top:
| Tab | What it holds |
| - | - |
| **Findings** | Every open and closed finding in your organization, grouped. |
| **Commitments** | Every commitment across every finding, sorted by due date. |
| **Sources** | Documents you uploaded so Coverbase can extract findings from them. |
Configuration for the module is on a separate page. Open the **Actions** menu on the Findings page and choose **Findings Settings**, or find **Findings Settings** on the Configuration page. Only people who can edit organization settings see it.
<Frame>
<img alt="Findings list grouped by vendor with insight cards" />
</Frame>
## How a finding gets raised
Every finding records a source. The **Source** column on the list names it, and the finding page links back to it.
| Source | Where you raise it | What it links |
| - | - | - |
| Assessment | An issue on the **Issues** tab: **Add Finding**, or select several and choose **Create one finding** or **Create a finding per issue** | The assessment and the issues (**Related issues** on the finding) |
| Vendor | **Actions**, then **New Finding** on the Findings page, or from the vendor record | The vendor only |
| Document | The **Sources** tab, after extraction | The uploaded document and the quoted passage |
| Radar alert | A Radar signal's actions menu, **Bulk create findings** | The alert and the vendors it exposes |
| Contract | A clause review: **Create finding** on a flagged clause | The contract and the clauses (**Source clauses** on the finding) |
| Zero Touch run | **Create findings** on a control in the run | The run's assessment |
| Security intelligence | **Raise finding** or **Generate findings** on the vendor's rating | The vendor |
| Dark web exposure | **Escalate to finding** on an exposure, on the **Dark Web** page or a vendor's **Dark Web** tab | The exposure, and its vendor when it has one. See [Dark web monitoring](/user-guides/dark-web-monitoring) |
| Screening match, Inspect evaluation, Risk | The match, the evaluation, or the risk register entry | That record |
A vendor is required only on the manual path. A finding raised from an assessment inherits the assessment's vendor.
**Bulk create findings** in the **Actions** menu does two jobs at once: the **Documents** tab creates findings from accepted extraction candidates, and the **Assessments** tab lists an assessment's open issues that do not yet have a finding, so you can create one per issue in a single pass with **AI autofill all findings**.
## Reading the list
The list is grouped, and a page is a page of groups. **Group by** offers **Vendor**, **Control Set**, **Assignee** and **Risk Level**. The column that matches the grouping is hidden automatically, since the group header already shows it.
| Column | What it shows |
| - | - |
| **Title** | The finding title. Click the row to open it. |
| **Vendor** | The vendor, or the assessment's vendor. |
| **Source** | Source type and name. Hover for the full name. |
| **Status** | The finding status badge. |
| **Controls** | Up to two control badges plus a count. Hover one to see the expectation and open the control. |
| **Assignee** | The owner, or *Unassigned*. |
| **Due Date** | The date with a colored dot. The dot goes quiet once the status is in a terminal group. |
| **Created** | When the finding was raised. |
| **Risk Level** | The stored risk level. |
| **Commitments** | How many commitments the finding has. |
Your custom fields on findings appear as extra columns. Use the display options button next to the filter to show, hide, reorder and pin columns, and **Expand All** / **Collapse All** to open or close every group.
**Filters** cover Vendor, Status, Due Date, Created Date, Updated Date, Assignee, Created By, Source Type, Source document, Risk Level, Control Set and Commitment Count. The search box matches titles. Save a filter, sort and column layout as a view from the view selector; the built-in view is **Findings**, showing everything.
The insight cards on the left summarize the whole dataset, not the current page: created versus resolved over 30 days, due dates split into pending, completed and overdue, the share of findings with a commitment, and leaderboards for assignees, vendors and control sets. Hide them with the arrow button next to the search box.
### Acting on several findings
Tick rows, or the checkbox on a group header, and a bar appears with **Change Stage**, **Change Assignee** and **Archive**. Shift-click selects a range. Moving several findings into a resolution status asks you to confirm, because it also resolves their connected assessment issues (see [Statuses](#statuses)).
Each row also has its own menu: **View details**, **View commitments**, **Request commitment** and **Archive**. Archiving is not reversible from the UI.
## The finding record
Click a row to open `/findings/<id>/overview`.
<Frame>
<img alt="Finding detail page with lifecycle card, details card and overview tab" />
</Frame>
The header shows the vendor (click it to open the vendor), the title (click to edit), a **Due** badge (click to pick a date or **Clear due date**) and a copy-link button. The **Actions** menu offers **Show in context**, which opens the finding inside its assessment's Issues tab, and **Archive**.
The left column holds these cards:
* **The status card.** The current status with the path before and after it. Pick a new status here.
* **Risk acceptance.** Appears while the finding is **Risk accepted**, and afterwards once an acceptance has been recorded on it. It shows who approved the acceptance, the justification, and when it expires. See [Accepting risk](#accepting-risk).
* **Details.** **Severity**, **Urgency** and **Risk Level** (or only **Risk Level**, depending on your settings), **Assignee**, **Watchers** (people or departments) and **External ID**. The External ID row appears when your organization imports findings from another system, and it must be unique.
* **Risks.** Risk register entries tied to this finding, with a link to add one.
* **Properties.** Your custom fields, with **Add Custom Field** for admins.
The right column has five tabs:
| Tab | What you do there |
| - | - |
| **Overview** | Edit the **Description**, manage **Related issues** and **Assessments**, see the source document, extraction evidence or source clauses, and read or add notes. A finding raised from an Inspect evaluation also shows **Recommended Remediation**: suggested steps to fix it, which you can edit or clear. |
| **Commitments** | The finding's commitments. **New commitment**, **Configure portal**, and **Review** on a commitment with a new vendor response. |
| **Documents** | Upload evidence and add a note per document. Documents a vendor uploaded through the portal are marked **From portal**. |
| **Emails** | Emails linked to this finding, and **New Email** to draft one. |
| **Activity** | Every change, including system changes, with who made it and when. This is the audit trail. |
<Warning>
A finding with a vendor commitment and no assignee shows a warning on the Overview tab. Nobody is notified when the vendor responds until someone owns the finding.
</Warning>
## Statuses
Every organization starts with seven finding statuses. **Open** is the default a new finding lands in. The other six are set by the commitment workflow, so keep their meaning even if you restyle them or add your own under **Configuration**, then **Statuses**.
| Status | Group | Meaning |
| - | - | - |
| **Open** | Unstarted | Raised and waiting for someone to act. The default for a new finding. |
| **Finalizing response** | Unstarted | A commitment is waiting on the vendor or being negotiated. |
| **Mitigation underway** | Started | The vendor accepted the terms and is doing the work. |
| **Action required** | Started | The vendor declined a commitment, or a risk acceptance expired or was revoked. Someone on your side has to decide. |
| **Mitigated** | Completed | The work is done and accepted. |
| **Compensating control** | Completed | Another control already covers the gap. |
| **Risk accepted** | Canceled | You accepted the remaining risk. |
Three of them resolve the finding: **Mitigated**, **Compensating control** and **Risk accepted**. Moving into one of these while the source assessment is still running also resolves the connected issues. Coverbase asks first: "Mark finding as Mitigated? 2 connected issues on the ongoing assessment will also be marked as resolved." Compensating control is different: it marks the issues *no longer an issue*, because the gap was never open. Issues on a completed assessment are annotated, not changed.
A finding stops counting as overdue once its status is in the Completed or Canceled group, whichever status that is.
### Accepting risk
Moving a finding to **Risk accepted**, from the status card or with **Change Stage** on a selection, opens the **Accept Risk** dialog. Tick **Record a justification and expiry** to make the acceptance time-bound:
* **Justification** says why the risk is acceptable and what compensates for it. It is required once the box is ticked.
* **Expires On** defaults to 90 days from today and can be at most a year out.
* You are recorded as the approver.
Leave the box unticked and the status changes with nothing recorded and nothing expiring. Click **Accept risk** to apply it. On a selection, findings that are already **Risk accepted** are skipped.
<Frame>
<img alt="Accept Risk dialog with Record a justification and expiry ticked, a justification filled in, and an Expires On date 90 days out" />
</Frame>
The **Risk acceptance** card on the finding then shows **Approved by**, **Justification**, **Accepted** and **Expires**. A week before the expiry, the finding's assignee, watchers, the people named in its user-type custom fields and the approver are notified. When the expiry passes, the next daily check moves the finding to **Action required**, reopens any assessment issues the acceptance had resolved, and notifies the same people. **Revoke** on the card ends the acceptance early and moves the finding to **Action required**. Earlier acceptances stay listed under **Past exceptions** as expired, revoked or resolved.
A finding accepted before expiries existed shows **No expiry recorded**. Revoke it and accept it again to set one.
## Severity, urgency, risk and due dates
What you see in the **Details** card depends on [Findings settings](#findings-settings):
* **Matrix mode.** You pick **Severity** and **Urgency**, and the **Risk Level** is read from your organization's matrix. It cannot be set directly.
* **Risk-direct mode.** You pick the **Risk Level** yourself.
* **Neither.** No level fields appear.
Either way, the due date follows the risk level when you have set offsets. When a finding's risk level changes, the due date is recalculated from today plus the days configured for the new level. When the risk level does not change, a due date you set by hand stays.
## Commitments
A commitment lives under a finding and is negotiated with the vendor through a portal. One finding can carry several, for example one per remediation step.
<Frame>
<img alt="Request commitment dialog with one commitment per finding" />
</Frame>
### Requesting one
<Steps>
<Step title="Pick the findings">
On the **Findings** tab, group by vendor and click **Request commitment** on the vendor's group header. The group enters selection mode with the eligible findings pre-ticked. Adjust the ticks and click **Continue**. For a single finding, use **Request commitment** from the row menu instead, or **New commitment** on the finding's **Commitments** tab.
</Step>
<Step title="Write the terms">
The dialog opens as **New commitments for \<vendor>**, one form per finding. Each needs a description of what the vendor must do and a due date. **AI autofill** drafts the description from the finding; **Use finding description** copies it verbatim. A finding that already has an open commitment offers **Existing commitment** so you update it rather than create a duplicate. **Discard** drops a finding from the request.
</Step>
<Step title="Send the portal invitation">
Click **Send portal invitation**. The next step sends the vendor a portal link by email. **Skip invitation** creates the commitments without emailing, which is right when you will send the link yourself or the vendor already has it.
</Step>
</Steps>
Every vendor has one persistent commitment portal. **Configure portal** on the group header or the finding's Commitments tab opens it, including a per-portal **Response window** that overrides the organization default.
### Commitment statuses
<Frame>
<img alt="Commitments tab listing commitments with status, due date, latest response, awaiting since and response due columns" />
</Frame>
| Status | Meaning |
| - | - |
| **Pending response** | Sent. The vendor has not answered. |
| **Finalizing terms** | The vendor answered with something other than a plain acceptance, and the terms are being settled. |
| **Mitigation underway** | Terms agreed. The vendor is doing the work. |
| **Declined** | The vendor refused. |
| **Closed** | Done, accepted, or closed by you. |
Overdue is not a status. The due date badge turns red on its own, except on Closed and Declined commitments.
A vendor can answer in the portal with **Accepted**, **Proposed changes** (a different date or wording), **Compensating Control** (an existing control already covers it), **Declined**, or later **Commitment Completed** with evidence. The **Commitments** tab lists **Latest response**, **Awaiting since** and **Response due** so you can see who the ball is with.
If your organization uses the [centralized supplier portal](/user-guides/centralized-supplier-portal), the vendor sees each commitment there with the finding's severity and where it came from: the assessment, contract or document it was raised in. Internal sources, such as a Radar alert, are never named to the vendor.
### Working a commitment
Click a commitment on the **Commitments** tab, or on a finding's **Commitments** tab, to open the **Commitment Details** drawer. The left side shows the status card with guidance and the actions for that state, the parent finding and its source, the **Assignee**, and the **Commitment Terms** with their due date. The right side has **Responses** (the vendor's rounds and the portal URL), **Documents**, **Notes** and **Activity**.
<Frame>
<img alt="Commitment details drawer with lifecycle actions and vendor responses" />
</Frame>
| When | Actions | What happens |
| - | - | - |
| Waiting on the vendor | **Send reminder** | Emails the vendor the portal link again. |
| Vendor proposed changes | **Review proposal** | Opens the terms for editing, with **Use proposed date** and **Use proposed text** shortcuts. **Update request** sends the revised terms back with an optional note to the vendor. The vendor's acceptance then confirms the commitment. |
| Vendor claims a compensating control | **Accept compensating control** or **Re-request** | Accepting closes the commitment. Re-requesting sends the ask back with your message. |
| Mitigation underway | **Mark complete**, **Send reminder**, **Revisit terms**, **Extend** | Mark complete closes it without a vendor submission. Extend moves the due date, records a note, and emails the vendor. Revisit terms reopens the round if the vendor accepted by mistake. |
| Vendor submitted completion | **Accept completion** or **Request more work** | Accepting asks for an optional closing note, then closes the commitment and accepts the submission. Requesting more work sends the round back. |
| Declined | **Accept risk** or **Re-request** | Accept risk closes the commitment, records your rationale, and moves the finding to **Risk accepted**. |
When a vendor submits completion evidence, claims a compensating control, proposes changes or declines, an **AI Review** card appears on the Responses tab with a suggestion, a confidence level and the reasoning. The card offers the two answers that fit that response, with the suggested one marked: **Accept and close** or **Request more work** for a completion, **Accept and close** or **Re-request** for a compensating control, **Adopt proposed terms** or **Keep current terms** for proposed changes, and **Accept risk** or **Re-request** for a decline. A send-back answer takes an optional **Message to vendor**. **Re-run review** tries again. Whether a review applies itself without you is a setting (see below).
The status picker at the top of the status card is an override. It changes the status and nothing else: no email, no portal change. Use the actions above when the vendor is involved.
### How commitments set the finding status
Every commitment change re-derives the parent finding's status from all of its commitments:
| Commitments | Finding becomes |
| - | - |
| Any declined | **Action required** |
| Otherwise, any pending or finalizing | **Finalizing response** |
| Otherwise, any mitigation underway | **Mitigation underway** |
| All closed, at least one by compensating control | **Compensating control** |
| All closed, every one after a decline | **Risk accepted** |
| All closed otherwise | **Mitigated** |
## Emails and notifications
Internal notifications go to the finding's assignee and to anyone named in a user-type custom field on the finding. The two risk acceptance notifications also go to the finding's watchers and to the approver. Each person turns them on or off in their own notification settings; the defaults are in the [notification catalog](/user-guides/email-notifications#the-notification-catalog).
| Notification | Fires when | Default |
| - | - | - |
| Finding assigned | A finding is assigned to you | On |
| Finding status changed | The status changes | Off |
| Finding risk changed | The risk level changes | Off |
| Finding due reminder | Due next week, due this week, and overdue | Off |
| Commitment created | A commitment is created on your finding | Off |
| Commitment status changed | A commitment changes status, including by AI review | Off |
| Commitment due reminder | A commitment is due next week, this week, or overdue | Off |
| Portal commitment submission | The vendor responds through the portal | On |
| Finding risk acceptance expiring | A week before a risk acceptance on your finding expires | On |
| Finding risk acceptance expired | The acceptance expired and the finding returned to **Action required** | On |
Vendor-facing email is separate: the portal invitation when you send a request, **Commitment updated** when you change the terms or extend a due date, and **Commitment reminder** when you click **Send reminder**. Coverbase also sends vendors automatic reminders on open commitments; see [Vendor-facing email](/user-guides/email-notifications#vendor-facing-email).
## Where findings show up elsewhere
* **Assessments.** The assessment's **Findings** tab and each issue's **Findings** panel list the findings raised there. A finding can be attached to more than one assessment from its Overview tab.
* **Vendors.** Archiving a vendor archives its findings that have no active linked assessment.
* **Risk register.** The finding page's risks card links register entries to the finding, and a finding can be raised from a risk.
* **Dashboards.** The [chart library](/user-guides/dashboard-library) includes findings charts, and they are available in every workspace.
* **Excel.** **Actions**, then **Download as Excel** builds a consolidated findings report, optionally with the current filters and column visibility.
* **API and integrations.** The [Findings API](/api-reference/findings) lists, creates and status-syncs findings for GRC round-trips; finding and commitment changes emit [webhook](/integrations/webhooks) events; and the [MCP server](/mcp/overview) answers questions about findings.
## Findings settings
Open **Actions**, then **Findings Settings**. Everything on this page applies to the whole organization, and only people who can edit organization settings can change it.
<Frame>
<img alt="Findings settings page with risk matrix and due dates by risk level" />
</Frame>
<Steps>
<Step title="Choose your scales">
**Risk levels** is the one that matters; **Urgency levels** and **Severity levels** are optional. Pick an existing level set or create one. Configure all three for matrix mode, only risk for risk-direct mode, or none. Two out of three is rejected on save.
</Step>
<Step title="Fill the risk matrix">
With all three scales set, the **Risk matrix** appears with a suggested mapping. Pick a risk level in the bar, then click or drag across cells. Every severity and urgency pair needs a value before you can save.
</Step>
<Step title="Set due dates by risk level">
Under **Due dates by risk level**, enter days per level. Leave a level blank for no automatic due date.
</Step>
<Step title="Save">
Click **Save changes**. Leaving the page with unsaved edits prompts you.
</Step>
</Steps>
<Warning>
Clearing the urgency or severity scale deletes the matrix. Clearing the risk scale also deletes the due-date offsets and removes the risk level field from every finding. Coverbase confirms before either.
</Warning>
Below that, **Commitment Settings** has its own **Save changes**:
* **Response window.** Days a vendor has to respond after a commitment is sent. It drives the **Response due** column and the overdue-response state. Leave it empty to track waiting time without a deadline. A portal can override it.
* **AI Review.** **Auto-Apply** decides whether an AI review acts on its own: **Suggest only** keeps a person in the loop; the high, medium and any-confidence options let it close commitments and send revision requests without review. **Review Instructions** is text added to every review, for example the evidence you require before accepting a completion.
## Permissions
Admins and Members create and edit findings and commitments. Siloed Members can only touch findings on vendors they own, watch or analyze. Recording a justification and expiry when you accept risk needs an Admin or Member role, or a custom role with the finding approve permission. Archiving, exporting and creating are separate permissions in a custom role, and portal actions (sending a reminder, re-requesting, pushing back a completion) need the portal update permission. A grayed-out action shows a "no permission" tooltip. Details: [Permissions and roles](/user-guides/permissions-and-roles).
## Troubleshooting
| What you see | What is happening |
| - | - |
| "I set the status to Mitigated and it went back to Finalizing response." | The finding has an open commitment. Its status is derived from commitments. Close the commitment instead. |
| "Risk Level is gray and I cannot pick it." | You are in matrix mode. Set **Severity** and **Urgency**; the risk level is read from the matrix. |
| "Your risk matrix is empty." | Matrix mode is configured but no cells are filled. Open **Findings Settings** and fill the matrix. |
| "No risk level is mapped for this combination." | The matrix has a gap for that severity and urgency pair. Fill it in settings. |
| "I changed the risk level and the due date moved." | Due-date offsets are on. A risk change recalculates the due date from today. Set the date by hand afterwards if you need a different one. |
| "**Request commitment** is not on the group header." | The group is not a vendor group, or the findings have no vendor. Group by **Vendor**, and give the finding a vendor. |
| "The vendor responded but nobody was told." | The finding has no assignee. Notifications go to the assignee and user-type custom fields. |
| "Two connected issues were resolved when I closed the finding." | That is the cascade. A resolution status on a running assessment resolves the issues the finding was raised from. Coverbase asked first. |
| "**Extend** is missing on the commitment." | Extend only exists while mitigation is underway. Before that, edit the terms; after Closed or Declined there is no live deadline. |
| "**Findings Settings** is not in the Actions menu." | You cannot edit organization settings. Ask an admin. |
| "A **Risk accepted** finding moved to **Action required** on its own." | Its risk acceptance expired, or someone clicked **Revoke**. The **Risk acceptance** card lists it under **Past exceptions**. Accept the risk again with a new expiry, or work the finding. |
| "**Accept risk** is grayed out once I tick **Record a justification and expiry**." | Your role cannot approve risk acceptances. Untick the box to move the finding to **Risk accepted** without an expiry, or ask an Admin. |
## Related
<CardGroup>
<Card title="How to run an assessment" icon="list-check" href="/user-guides/running-an-assessment#part-5-work-the-issues">
Where most findings come from: working the issues and promoting the real gaps.
</Card>
<Card title="Analyst and reviewer guide" icon="user-check" href="/user-guides/analyst-reviewer#dispositioning-issues">
Accept the risk, keep the follow-up open, or promote to a finding.
</Card>
<Card title="Email and notifications" icon="envelope" href="/user-guides/email-notifications">
Every email the platform sends, who receives it, and the defaults.
</Card>
<Card title="Findings API" icon="code" href="/api-reference/findings">
List, create and status-sync findings from your GRC platform.
</Card>
</CardGroup>
# Front Door triage
Source: https://docs.coverbase.com/user-guides/front-door-triage
Set up and run the Front Door review of intake requests: the reuse window and sign-off groups, IRQ scoping rules, the Do Not Use list, checking identifiers, choosing a disposition, signing it off or declining it, sending questions back to the requester, and the budget and material change cards.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Front Door** tab of an intake request and the **Configuration → Front Door** settings. It sits beside [Requesting a new vendor](/user-guides/requesting-a-vendor), which covers the requester's side, and [The engagement record](/user-guides/engagement-record), which picks up once due diligence starts. For what the module is, see [Front Door](/products/front-door).
</Info>
The Front Door is where the TPRM Office decides what an intake request needs before anyone sends a questionnaire. You answer four questions on one tab: is this a new vendor, can earlier due diligence be reused, is an inherent risk questionnaire (IRQ) required, and is the vendor on the Do Not Use list. The answers become a disposition that two people sign off.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
The mistake people make most often is signing off a disposition and then revising it to fix a typo in the rationale. Revising clears both sign-offs, so both signers have to sign again.
## Before you start
You need the Admin role, or a role that can change organization settings, to change the Front Door settings. Triage itself needs permission to review intake requests.
Decide three things with your team first:
* Which user group is the **TPRM Office** and which is **Supply Chain**. Each disposition needs one sign-off from each, by two different people.
* How old a completed assessment can be and still be reused. The default is 12 months.
* Whether an IRQ is required by default, and which intake answers should change that.
## Step 1: Configure the Front Door
Open **Configuration** and choose **Front Door**.
<Frame>
<img alt="Front Door settings page with Reuse Window set to 12 months, TPRM Office and Supply Chain groups chosen, IRQ required by default turned on, and three IRQ scoping rules" />
</Frame>
<Steps>
<Step title="Reuse and Sign-off">
Set **Reuse Window (Months)**. A completed assessment younger than this can be proposed for reuse on a similar engagement. Choose the **TPRM Office Group** and the **Supply Chain Group**. Left on **Any reviewer**, anyone who can review the request may sign for that role, but the two sign-offs must still come from different people.
</Step>
<Step title="IRQ Scoping Rules">
Choose whether **IRQ required by default** is on. Then click **Add rule** for each exception. In the rule dialog, give a **Rule Name** (for example, "processes consumer personal data") and add **Conditions**: each picks a **Questionnaire** and a **Question** from your intake and holds **When the Answer** **is any of** or **is none of** the **Answers** you choose. Every condition must hold for the rule to fire; **Add condition** adds another. The **Outcome** is **Require the IRQ**, with the **IRQ Templates** to send (with none chosen, the standard IRQ is sent), or **No IRQ needed**. Click **Update rule** to put it in the table.
</Step>
<Step title="Save">
Rules are listed in a table with their conditions, outcome and **Enabled** switch. Select several to **Enable**, **Disable** or **Remove** them together. Click **Save**; until you do, the page shows **You have unsaved changes**. Saving rules that differ from the last saved set increases the rule set version shown in the description. Each disposition records the version and the rules that fired when it was decided, so later edits do not rewrite past decisions.
</Step>
</Steps>
How rules combine: a firing rule that requires the IRQ wins over a firing exemption. With no rule firing, **IRQ required by default** decides.
## Step 2: Mark vendors you must not use
Open the vendor, find the **Do Not Use** card on the overview, and click **Mark Do Not Use**. Give a **Reason**, then click **Add to Do Not Use**.
To take the vendor off the list, click **Remove from Do Not Use**. The confirmation asks for a **Reason for removing**, and Coverbase refuses the removal without one. Both reasons are capped at 2,000 characters, and a counter under the field shows how many you have used. Every change, on or off, is recorded in the vendor's activity with who made it and why.
A Do Not Use vendor can still be requested. The requester is warned that a reviewer must approve an exception, and approving the request needs an override rationale (step 6).
## Step 3: Open a request
Open **Intake** in the left navigation and choose the request. The request opens on the **Front Door** tab. **Submission** shows the requester's answers.
If the request started as a purchase requisition in a connected procurement system, a **Started From Procurement** card shows the **Source**, **Value**, **Category** and when it was **Synced**. See [Integration Hub](/user-guides/integration-hub).
## Step 4: Is this new?
The **Is This New?** card compares the request with your vendors.
| Badge | Meaning |
| - | - |
| **Tax ID exact**, **D-U-N-S exact**, **LEI exact** | A registry identifier matched. Shown as **Deterministic match**, with how many of the three identifiers agree. |
| **Domain exact**, **Name similar** | Only the website or the name matched. Shown as **Probabilistic match**. Check the vendor before you treat it as the same company. |
| **Linked** | The request was already linked to this vendor. |
If the requester did not give identifiers, enter the **Tax ID**, **D-U-N-S** (9 digits) or **LEI** (20 letters and digits) yourself and click **Check identifiers**. A stored tax ID is shown only as its last four characters.
For an existing vendor, the card then finds the most similar engagement, ranked by shared services and tags, and tells you whether its due diligence is **inside** or **outside** the reuse window. **Choose the engagement to compare** picks a different one. The comparison lists the services the two share and the attributes they differ on.
## Step 5: Decide reuse and record the disposition
When a similar engagement has completed due diligence, **Proposed Reuse by Domain** lists each risk domain with its **Prior Result** and a **Proposal**: **Reuse prior due diligence**, **Abbreviated review** or **New due diligence**. Change any proposal you disagree with.
Then pick the **Disposition**:
* **Add as new engagement, reuse due diligence** reuses the domains you marked for reuse.
* **Extend the existing engagement** treats the request as an amendment. No new engagement is created.
* **Full new due diligence** ignores prior results.
Write the **Rationale**, which is required, kept in the audit trail and shown to both sign-off groups, and click **Record disposition**. The card then shows **Awaiting sign-off**. Each signer clicks **Sign off as** their role, or **Approve triage** at the top of the request, which signs off the recorded disposition for their group. The disposition is **Decided** when the second, different person signs.
<Frame>
<img alt="Front Door tab with Send back with questions, Decline and Approve triage buttons in the header, and a disposition card showing the TPRM Office signed off and Supply Chain awaiting" />
</Frame>
<Warning>
**Revise disposition** asks you to confirm, then clears both sign-offs. Once an assessment has launched from the disposition, it is locked and can no longer be revised.
</Warning>
### Decline a disposition
To send a disposition back instead of signing it, click **Decline** beside **Approve triage**. Only a member of a sign-off group that has not signed yet can decline, and only before the disposition is decided. Write the **Reason** (what needs to change before your group can sign off) and click **Decline and send back**. The reason is required.
What a decline does:
* The disposition goes back to the TPRM Office as a draft, labeled **Back with the TPRM Office**. Any sign-off already given is cleared.
* The disposition shows who declined, for which group, and why. The **Audit Trail** records the same.
* The TPRM Office and whoever recorded the disposition are notified with the reason. The requester is told that the TPRM Office is revising the decision.
* Nobody can sign off or decline until the disposition is recorded again.
To ask both groups again, the TPRM Office revises the disposition and clicks **Record again**. That clears the decline, and both groups sign off afresh.
<Frame>
<img alt="Disposition card labeled Back with the TPRM Office, showing that Dana Sato declined for Supply Chain with the reason, a Record again button, and the audit trail entry for the decline" />
</Frame>
### Decide from Microsoft Teams
With [Teams approvals](/integrations/guides/microsoft-teams#register-the-bot) on, Coverbase posts one card for both sign-off groups, and each group can sign off or decline from it. Declining from Teams does the same as **Decline** in Coverbase. A card for a disposition that has since been revised is refused, so nobody signs a decision they did not see.
A sign-off or decline made in Coverbase also updates the Teams card. The card then shows who signed and which group is still waiting, the decided disposition, or who declined and why, and it cannot record a second decision.
### What happens when it is decided
* **The IRQ is sent once.** If an IRQ is required, the templates go to the requester as soon as the second sign-off lands. If the request has no vendor or requester yet, the card says **Required but not sent yet**; click **Send IRQ** once it does.
* **Reuse waits for the next assessment.** The vendor's next assessment launched from an assessment plan drops the control sets for reused domains and copies the prior scores for them, labeled with their source. Zero Touch assessments do not use it.
## Step 6: Handle a Do Not Use vendor
When the vendor is on the list, a banner names it and shows the reason. Enter an **Override rationale** and click **Record override** before approving the request. Approval without one is refused. The override applies to this request only, and is kept in the audit trail.
<Note>
A workflow that approves intakes automatically skips a request whose vendor is on the Do Not Use list, because no one is there to give a rationale.
</Note>
## Step 7: Ask the requester
Click **Send back with questions**, write one or more questions, and **Send**. The requester is notified and answers inside their request, including an anonymous requester on a public portal. Questions and answers stay under **Questions for the Requester** and in the **Audit Trail**.
## Budget and material change
Two more cards appear when the requester filled in the matching intake steps.
* **Budget.** Shows the request amount, its amortization and **First year's draw** against the synced budget line's remaining balance, with **Within budget** or **Exceeds budget**. Coverbase works this out from the synced line, not from figures the requester typed. A line the procurement system reports no committed figure for shows **Unknown**. If the requester asked for a budget exception, **Approve exception** or **Decline exception**, with an optional **Decision rationale**.
* **Material Change.** For an existing vendor, lists what the requester flagged as changed, such as a new offshore location, a new AI use case or a new subprocessor, with **Needs IRQ refresh**. **Refresh IRQ** opens an IRQ refresh on the engagement's monitoring plan for its Transaction Owner to answer. See [IRQ refresh](/user-guides/monitoring-plans#step-5-refresh-an-irq).
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **Front Door** tab on the request | The third-party lifecycle features are not turned on for your organization. | Ask your Coverbase representative. |
| **Probabilistic match** on a vendor you know is the same | Only the name or website matched. | Enter a tax ID, D-U-N-S or LEI and click **Check identifiers**. |
| **Approve triage** is unavailable | No disposition is recorded, there are unsaved disposition changes, you already signed, or you are in neither sign-off group. | Follow the reason shown on the button. |
| **Sign off** does nothing for the second signer | The same person tried to sign both roles, or is not in the role's group. | A different member of the other group signs. |
| Both sign-offs disappeared | Someone clicked **Revise disposition**, or a sign-off group declined. | Both signers sign the revised disposition. After a decline, the TPRM Office clicks **Record again** first. |
| **Decline** is not shown | Your group already signed, you are in neither sign-off group, or the disposition is already decided or already declined. | Ask a member of the group still waiting. |
| **Back with the TPRM Office** and nobody can sign | A sign-off group declined the disposition. | Read the reason, revise the disposition, and click **Record again**. |
| **Remove from Do Not Use** does nothing | The **Reason for removing** is empty. | Write a reason, up to 2,000 characters. |
| **Required but not sent yet** | The request had no vendor or requester when it was decided. | Link the vendor, then click **Send IRQ**. |
| Approving the request returns an error about the Do Not Use list | No override rationale was recorded. | Record an override rationale, then approve. |
| The new assessment did not reuse anything | It was a Zero Touch assessment, or not launched from an assessment plan, or the reuse was already applied to an earlier one. | Launch from an assessment plan. Check the **Audit Trail** for **Disposition applied to the launched assessment**. |
| The budget card says **Unknown** | The procurement system has no committed figure for that budget line. | Check the line in your procurement system, then sync again. |
| **Refresh IRQ** says there is nothing to refresh | The vendor has no engagement under an active monitoring plan. | Generate a monitoring plan for the engagement first. |
## Related
<CardGroup>
<Card title="Requesting a new vendor" icon="cart-shopping" href="/user-guides/requesting-a-vendor">
What the requester sees, including Front Door notices.
</Card>
<Card title="The engagement record" icon="route" href="/user-guides/engagement-record">
Linked and reused diligence, and the Risk Summary.
</Card>
<Card title="Risk methodology" icon="scale-balanced" href="/user-guides/risk-methodology">
How the IRQ is scored and who reviews each domain.
</Card>
<Card title="Front Door" icon="door-open" href="/products/front-door">
What the module does and does not do.
</Card>
</CardGroup>
# Global financial coverage
Source: https://docs.coverbase.com/user-guides/global-financial-coverage
Which markets Coverbase reads audited annual statements from, how each source is read, and what to do when a vendor has nothing on file.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers where the filed figures on a vendor's **Financial health** tab come from. To learn how Coverbase scores those figures, see the [Financial health guide](/user-guides/financial-health-score).
</Info>
Coverbase reads a vendor's audited annual statements from seven sources, tried in a fixed order, so it can rate listed companies in the US, the UK, most of the EU and EEA, Korea, Brazil, Japan, and any market where the company publishes an annual report. Your credit methodology needs these figures from the latest audited year: current assets, current liabilities, total liabilities, equity, operating profit, interest, and cash flow.
## How Coverbase chooses a source
Coverbase tries each source in this order and stops at the first one that has the vendor's latest annual statements. Sources that publish tagged data come first. Coverbase reads a published annual report only when no tagged source has the company.
| Order | Source | What it covers |
| - | - | - |
| 1 | **SEC EDGAR** | US companies that file a 10-K. Foreign companies that file a 20-F or 40-F with the SEC, for example many large Canadian, Israeli, Swiss, Japanese, Indian and Latin American companies. |
| 2 | **ESEF and UKSEF annual reports** | Listed companies in the UK and most of the EU and EEA, for example Denmark, Sweden, France, Finland, Norway, Poland, Italy, Belgium, the Netherlands, Austria, Spain and Portugal. |
| 3 | **OpenDART** | Korean listed companies, and unlisted Korean companies that file audited reports. |
| 4 | **Companies House** | UK companies that file tagged accounts, private companies included. Small and micro companies that file only a balance sheet still get a current ratio and a debt-to-worth ratio. |
| 5 | **CVM** | Brazilian listed companies, matched by CNPJ. |
| 6 | **EDINET** | Japanese companies that file an annual securities report, matched by securities code or corporate number. |
| 7 | **Published annual report** | Listed companies that publish an annual report on their own website or through their exchange, for example in Australia, Hong Kong, Singapore, New Zealand, Switzerland, Germany, Ireland, South Africa, India, and Canadian companies that do not file with the SEC. |
The **Financial health** tab names the source above the ratings, for example "Rated from SEC Form 10-K, fiscal year 2025" or "Rated from Annual report, fiscal year 2026". To check a figure, click **Open filing**. It opens the document Coverbase read.
## How Coverbase reads each source
* **SEC EDGAR, ESEF, UKSEF, OpenDART, Companies House, CVM and EDINET** tag each figure with a standard taxonomy or chart of accounts: US GAAP, IFRS, the UK FRC taxonomy, the Brazilian standard chart, or the Japanese GAAP taxonomy. Coverbase reads only the standard tags for consolidated totals. When a company tags a line with its own custom element, Coverbase leaves that figure blank. Some ESEF filers show no capital expenditure or interest for this reason.
* **Published annual reports** are PDFs. A model reads the pages that hold the primary statements and the auditor's report. Coverbase then checks the result in three ways:
* The company named in the report must be your vendor.
* The report must come from the vendor's own website or from an exchange that publishes for it. The vendor's site on its home country's domain also counts, for example telstra.com.au for an Australian vendor recorded as telstra.com.
* Total assets must be within 2% of total liabilities plus equity. If they are not, Coverbase drops total liabilities and the debt-to-worth ratio.
<Warning>
A model can misread a figure in a published annual report. The 2% balance check catches large errors, not small ones. Before you rely on a rating from an annual report, open the filing and check the figures behind it.
</Warning>
## Audit status
Your methodology can require audited statements before a vendor rates Low. Coverbase decides whether the latest full year is audited from the source.
| Source | How Coverbase decides |
| - | - |
| SEC EDGAR, ESEF and UKSEF | The law requires an audit of these annual reports. The year counts as not audited when the next annual report is overdue. |
| OpenDART | DART publishes the auditor's opinion. An adverse opinion or a disclaimer counts as not audited. |
| Companies House | The accounts type, then the audit status the accounts declare in their tags. Audit-exempt small companies, micro-entities and dormant companies count as not audited. |
| CVM | The auditor's report type CVM publishes. An adverse opinion or a disclaimer counts as not audited. |
| EDINET | The law requires an audit of the annual securities report. The year counts as not audited when the next report is overdue. |
| Published annual report | The model reads the auditor's report in the document. |
A report counts as overdue when the next year's report is past this deadline after the fiscal year end:
| Source | Deadline |
| - | - |
| SEC EDGAR | 120 days |
| ESEF and UKSEF | 120 days |
| OpenDART | 90 days |
| Companies House | 275 days |
| CVM | 90 days |
| EDINET | 92 days |
| Published annual report | 183 days |
## When a vendor has nothing on file
**Nothing on file to rate** means no source had audited annual statements for the vendor. You see it in these cases:
* The vendor is a private company outside the UK and Korea. These companies publish no statements.
* The vendor is a bank or an insurer. These companies do not split current from non-current items, so Coverbase does not rate the current ratio.
* Coverbase could not confirm the vendor's identity. Coverbase finds each source from the LEI, company number or stock ticker on the **Corporate registration** tab. When several registered companies share the vendor's name, Coverbase prefers the one registered in the vendor's headquarters country and the group parent over its subsidiaries. When nothing separates them, the match waits for review instead of choosing one.
To rate a vendor with nothing on file, click **Upload financial statements** on the **Financial health** tab and add the statements the vendor gave you. Coverbase rates submitted statements the same way, and only your organization sees them. See [Submitting a vendor's own financial statements](/products/financial-health-score#submitting-a-vendors-own-financial-statements).
## Freshness
Coverbase reads the tagged sources each time it refreshes the vendor's intelligence. It reads a published annual report at most once every 90 days, because companies publish one each year.
## Troubleshooting
| What you see | What to check |
| - | - |
| A listed company reads **Nothing on file to rate** | Open the **Corporate registration** tab. If the LEI, company number or stock ticker is missing, Coverbase cannot match a source to the company. |
| The figures belong to a different company | Open the filing. If it names another company, contact Coverbase support with the vendor's name. Coverbase matches the filing from the registration, so the registration may point to the wrong company. |
| Capital expenditure or interest is blank for a European company | The company tagged that line with its own custom element. Coverbase still rates the other ratios. |
| A UK company's year reads as not audited | The company filed audit-exempt accounts. |
# Intake Agent
Source: https://docs.coverbase.com/user-guides/intake-agent
Turn on zero-form intake in Slack, Microsoft Teams, email and AI assistants, check each channel's status, and read the conversations the Intake Agent has with requesters.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Integration Hub → Intake Agent**. It sits beside [Requesting a new vendor](/user-guides/requesting-a-vendor) and [Front Door triage](/user-guides/front-door-triage). For what the agent is, see [Intake Agent](/products/intake-agent).
</Info>
<Note>
Your Coverbase representative turns on the third-party lifecycle features, including the Intake Agent, for your organization.
</Note>
The Intake Agent lets requesters ask for a new vendor by message instead of a form. Each channel is off until you turn it on.
The mistake people make most often is turning a channel on before vendor intake is set up. The agent opens requests through your intake portal. With no portal, it has nowhere to open them, and the page says so.
## Step 1: Open the Intake Agent page
Open the [Integration Hub](/user-guides/integration-hub) and click the **Intake Agent** card. Turning channels on or off needs permission to manage integrations. Others can see the channels and conversations.
Each channel shows a status: **Ready**, **Needs setup**, **Needs reinstall** or **Not available** (not offered on this Coverbase environment).
<Frame>
<img alt="Intake Agent page with Slack and Microsoft Teams channels marked Needs setup, Email and AI assistants marked Ready, each with an Off switch, and an empty Conversations table" />
</Frame>
## Step 2: Turn on the channels you want
| Channel | Requesters | Setup first |
| - | - | - |
| **Slack** | Send the Coverbase app a direct message, or mention it in a channel. The agent answers in a direct message. | Connect [Slack](/integrations/guides/slack). An install from before the Intake Agent was available shows **Needs reinstall**. Reinstall the app to grant it permission to read direct messages and mentions. |
| **Microsoft Teams** | Chat with your Coverbase bot. The agent answers in the same chat. | Register the bot and add its app ID and client secret on the [Microsoft Teams](/integrations/guides/microsoft-teams#register-the-bot) connection. People chat with the app in its personal scope. |
| **Email** | Email the intake inbox from their work account. Replies come back to the same thread. | Turning email on gives you the inbox address, `<organization>-intake@...`. Share it with requesters. |
| **AI assistants** | Describe what they need to Claude or another MCP client connected to Coverbase. | Connect the client to the [MCP server](/mcp/connecting). |
Switch the channel on. A toast confirms it now takes intake requests.
## Step 3: Follow the conversations
**Conversations** lists every request with the **Requester**, the **Request**, the **Channel**, the **Status** and the **Last Message**. Filter by channel.
<Frame>
<img alt="Conversations table with four requests: one from Microsoft Teams with Intake opened, two from Slack and email Waiting on requester with the number of answers still needed, and one from an AI assistant that Did not open" />
</Frame>
| Status | Meaning |
| - | - |
| **Waiting on requester** | The agent asked for something and is waiting. The row says how many answers are still needed. |
| **Intake opened** | The intake exists. **Open the intake** goes to it. |
| **Did not open** | The agent gave up, for example after five messages with something still missing. |
Open a conversation to see what the agent understood (**Vendor**, **What It Is For**, **Data It Touches**), what is **Still Needed**, the **Similar Approved Vendors** it named, and the whole **Thread**.
## What the requester sees
The agent replies with what it understood and a numbered question for each gap: the vendor, which existing vendor if the name matched several, what it is for, or what data it touches. "No company data" is an answer. When nothing is missing it replies with a link to the opened request. The request is not an approval: it goes to the Front Door like any other.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| **Vendor intake is not set up, so the agent cannot open requests yet.** | No intake portal exists. | Click **Set up intake**. |
| Slack shows **Needs reinstall** | The app was installed without permission to read direct messages and mentions. | Reinstall the Coverbase app in Slack. |
| Teams shows **Needs setup** | The Teams connection has no bot app ID and client secret. | Register the bot on the Microsoft Teams connection. |
| A requester's email got no reply | The sender is not an active member, or the message failed SPF. | Ask them to send from their work account. |
| A requester was told the channel is off | The channel is off for your organization. | Turn it on. |
| The agent matched the wrong vendor | The name or domain matched exactly. | Correct the vendor on the Front Door review. |
## Related
<CardGroup>
<Card title="Requesting a new vendor" icon="cart-shopping" href="/user-guides/requesting-a-vendor">
The form-based way in.
</Card>
<Card title="Front Door triage" icon="door-open" href="/user-guides/front-door-triage">
What happens to the intake.
</Card>
<Card title="Vendor intake through MCP" icon="robot" href="/mcp/vendor-intake">
The assistant side.
</Card>
<Card title="Agent Ledger" icon="book-bookmark" href="/user-guides/agent-ledger">
Every message the agent read.
</Card>
</CardGroup>
# Integration Hub
Source: https://docs.coverbase.com/user-guides/integration-hub
Connect Coupa, SAP Ariba, Ironclad, Icertis or Microsoft Teams, set up authentication and the signed webhook, review field mappings, read the sync log, work the steward queue, and use Spend Controls and Vendor Master Data.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Integration Hub** pages, **Configuration → Spend Controls** and **Configuration → Vendor Master Data**. It sits beside [Warehouse data share](/user-guides/warehouse-data-share) and [Webhooks](/user-guides/webhooks). Each provider has its own setup guide: [Coupa](/integrations/guides/coupa), [SAP Ariba](/integrations/guides/sap-ariba), [Ironclad](/integrations/guides/ironclad), [Icertis](/integrations/guides/icertis) and [Microsoft Teams](/integrations/guides/microsoft-teams). For what the module is, see [Integration Hub](/products/integration-hub).
</Info>
<Note>
Your Coverbase representative turns on the third-party lifecycle features, including the Integration Hub, for your organization.
</Note>
The Integration Hub is one page for every procurement, contract and messaging system your program touches. Each connection has the same tabs: **Field Mappings**, **Sync Log**, **Steward Queue** and **Authentication**.
The mistake people make most often is expecting a supplier to link by name. A supplier links only on a tax ID, a D-U-N-S number, an LEI or, when nothing stronger disagrees, a domain. Everything else waits in the steward queue until someone links it.
## Step 1: Open a provider
Open **Configuration**, choose **External Integrations**, and click **Coupa**, **SAP Ariba**, **Ironclad**, **Icertis**, **Archer**, **ServiceNow IRM**, **ERM Risk Register** or **Microsoft Teams**. Each card opens that provider in the Integration Hub. **Spend Controls** and **Vendor Master Data** also have **Open Integration Hub**.
The hub lists providers by category (**Procure-to-pay**, **Contract lifecycle**, **GRC and ERM**, **Messaging**) with their direction (**Two-way** or **Inbound only**), health (**Available**, **Healthy**, **Needs attention**, **Paused** or **Error**) and when each **Last synced**. Changing a connection needs permission to manage integrations. Without it, the page is read-only.
## Step 2: Authenticate
On the **Authentication** tab, fill in what the provider needs. The method is shown at the top: **OAuth 2.0 client credentials**, **API token** or **Incoming webhook**.
| Provider | Fields |
| - | - |
| Coupa | **Instance URL**, **Client ID**, **Client secret**. The scopes the OAuth client needs are listed. |
| SAP Ariba | **Client ID**, **Client secret**, **Application key**, **Realm**, and optionally the **Sourcing reporting view** |
| Ironclad | **Instance URL**, **API token** |
| Icertis | **Instance URL**, **Token URL**, **Client ID**, **Client secret**, and optionally the **Scope** |
| Archer | **Instance URL**, **Instance Name**, **User Domain**, **Service Account Username** and **Password**, and the issue and risk level and status field IDs. See [Archer](/integrations/guides/archer). |
| ServiceNow IRM | **Instance URL**, **Client ID**, **Client Secret**, and the **Issue Table** and **Risk Table**. See [ServiceNow IRM](/integrations/guides/servicenow-irm). |
| ERM risk register | **Instance URL**, **API Token**, and the register's paths, update method, ID field and token header. See [ERM risk register](/integrations/guides/erm-register). |
| Microsoft Teams | **Webhook URL**, the **Notification Types** to post, and for approvals and intake chats the bot's app ID, client secret and tenant ID. See [Microsoft Teams](/integrations/guides/microsoft-teams). |
Then choose:
* **Open an intake request for each new requisition** (Coupa and SAP Ariba), and the **Requisition Statuses** that should open one. Leave the statuses empty for all. On by default.
* **Write risk tier, approval status and contract values back to the provider** (Coupa, Ironclad and Icertis). On by default. Turn it off for a read-only connection.
* **Sync Interval (Minutes)**: 60 by default, 15 at the shortest.
Click **Save**, then **Test connection**. A stored secret is never shown again. The field reads **Stored. Enter a new value to replace it.**
## Step 3: Set up the webhook (optional)
A provider that can call a webhook can ask for a sync as soon as a record changes, instead of waiting for the interval. Under **Webhooks** on the **Authentication** tab, click **Create signing secret** and copy it at once, because it is not shown again. Give your provider, or the middleware in front of it, the webhook URL and the secret.
Each delivery must carry an `X-Coverbase-Signature` header of the form `t=<unix seconds>,v1=<hex digest>`, where the digest is HMAC-SHA256 of `<t>.` followed by the raw body, keyed by the signing secret. A delivery more than five minutes old, or with a wrong signature, is rejected. The body only identifies the record. Coverbase always re-reads the record from the provider's API. A webhook from Ironclad or Icertis that names a contract syncs only that contract, including a contract whose record ID is `0`. **Rotate signing secret** replaces the secret.
## Step 4: Review field mappings
The **Field Mappings** tab lists each mapping by **Object**, **Direction**, **Source** and **Target**. Inbound rows write provider values into Coverbase, such as a requisition's total into the intake request's value, or a supplier's tax ID into matching. Outbound rows write Coverbase values to the provider field you name, such as **Risk tier**, **Approval status**, **Residual risk**, **Risk rating**, **Required clause pack** or **Blocking issues**.
Type the provider's field name in **Target** for each outbound row, turn off **Enabled** on any row you do not want, and click **Save mappings**. **Discard changes** drops unsaved edits.
<Note>
The required clause pack is the high and critical clauses of your active clause sets, up to 25, by clause ID and name. It is the same for every contract. Blocking issues are the titles of the vendor's open findings, up to 20.
</Note>
## Step 5: Sync and read the log
Click **Sync now**. The **Sync Log** tab lists each run with when it **Started**, its **Trigger** (**Scheduled**, **Manual** or **Webhook**), **Status** (**Running**, **Succeeded**, **Partial** or **Failed**), record count and error. Open a run to see **Records in This Run**: each provider record, its **Outcome** (created, updated, unchanged, skipped, conflict or failed) and the detail. One bad record fails alone, and the rest of the run continues.
<Frame>
<img alt="Sync Log table with a scheduled run marked Partial, a webhook run marked Succeeded, and a manual run marked Failed because the provider rejected the stored credentials" />
</Frame>
**Pause** stops syncing, and **Resume** starts it again. **Disconnect** deletes the stored credentials and removes the connection's sync log, record links and steward queue.
## Step 6: Work the steward queue
Supplier records that did not match a vendor wait on the **Steward Queue**, with their **Identifiers**, a **Reason** (**No match**, **Several matches** or **Identifiers disagree**), and when they were **First Seen** and **Last Seen**. Filter by system, reason and age (for example **Waiting over 7 days**), and search by name or record ID. Pick the right vendor under **Vendor** and click **Link**, or **Dismiss**. A banner on the hub says how many records are waiting.
To work many at once, choose a vendor on each row you are sure of, select the rows, and click **Link chosen matches**, or **Dismiss**. The work runs in the background with progress, and the result reads, for example, "12 linked, 3 need a decision", naming each record it could not handle and why. Rows with no vendor chosen stay in the queue.
<Frame>
<img alt="Steward Queue table listing four Coupa supplier records with reasons Several matches, Identifiers disagree and No match, each with a vendor picker and Link and Dismiss buttons" />
</Frame>
A dismissed record comes back only if its identifiers change.
Linking a supplier is permanent for that record. A contract that synced before its supplier was linked is filed against the vendor, with its executed copy, as soon as you link the supplier.
## The Intake Agent
The hub's **Intake Agent** card opens zero-form intake: requests for a new vendor made in Slack, Teams, email or an AI assistant. See [Intake Agent](/user-guides/intake-agent).
## Approvals from Teams
With your Coverbase bot registered, the Microsoft Teams connection posts Front Door sign-offs, acceptance decisions and exit plan evidence with **Approve** and **Decline** buttons. People decide in Teams as themselves, with their own Coverbase permissions. The connection's **Approvals** tab lists every press and what it did. A Front Door card is replaced with the outcome whether the sign-off or decline happens on the card or in Coverbase. See [Microsoft Teams](/integrations/guides/microsoft-teams) for the bot setup.
<Frame>
<img alt="Decisions From Teams table listing a Front Door sign-off recorded, an acceptance decision declined with a reason, exit plan evidence already decided, a press not allowed, and a guest whose account was not matched" />
</Frame>
## What a synced requisition looks like
A requisition or sourcing event opens a draft intake request. The requester sees **Initiated from a Coupa purchase request** (or the provider's name), and the Front Door review shows **Started From Procurement** with the value and category. The supplier's identifiers go to the Front Door's **Is This New?** check. See [Front Door triage](/user-guides/front-door-triage).
## Spend Controls and Vendor Master Data
* **Configuration → Spend Controls** lists the budget lines synced from Coupa with **Budget**, **Committed**, **Remaining** and **Utilization**, and counts lines at or above 90% committed. Requesters map their spend to these lines during intake.
* **Configuration → Vendor Master Data** shows supplier master records from SAP Ariba or Coupa, with the steward queue and the sync log.
* A vendor's procurement tab shows its **Approved Supplier Lists** status from each connected system: **Approved**, **Not approved** or **Not stated**.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| **Connection failed** after **Test connection** | Wrong credentials, instance URL or token URL, or the OAuth client lacks a scope. | Check each field against the provider guide, then test again. |
| A supplier did not link | It matched on name only, several vendors matched, or its identifiers point to different vendors. | Link it from the **Steward Queue**. |
| Spend Controls shows no budget lines | The Coupa OAuth client lacks `core.budget.read`, or the provider does not publish budgets. | Add the scope to the client, then sync. |
| Nothing is written back to the provider | Outbound sync is off, an outbound row is disabled, or its **Target** is empty. | Turn on write-back on **Authentication** and name the target fields. |
| A run is **Partial** | Some records failed. | Open the run and read each failed record's detail. |
| Webhook deliveries are rejected | The signature is wrong, uses the parsed body, or the timestamp is more than five minutes old. | Sign the raw body with the current secret and a fresh timestamp. |
| Contracts sync but no executed copy is filed | The supplier has not been linked yet. | Link the supplier in the steward queue. |
## Related
<CardGroup>
<Card title="Front Door triage" icon="door-open" href="/user-guides/front-door-triage">
Where a synced requisition is reviewed.
</Card>
<Card title="Integration directory" icon="grid-2" href="/integrations/directory">
Every system Coverbase connects to.
</Card>
<Card title="Integration credentials and signing" icon="key" href="/security/integration-credentials">
How credentials and webhooks are protected.
</Card>
<Card title="Contract intake and approval" icon="clipboard-check" href="/user-guides/contract-intake-and-approval">
What happens when a contract is executed.
</Card>
</CardGroup>
# Internal controls monitoring with Inspect
Source: https://docs.coverbase.com/user-guides/internal-controls-monitoring
How to connect your own applications to Inspect, run an inspection against an internal control set, read the result, watch for drift between runs, keep probes and schedules running, and turn what it finds into findings.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Inspect** screens. For what the module is and how internal and third-party risk share one model, see [Internal control monitoring](/products/internal-controls-monitoring) and [Agentic Inspect](/products/agentic-inspect). For the control sets it evaluates, see the [Control Set library](/control-library).
</Info>
<Note>
Inspect is an optional module. If you do not see **Inspect** in the left navigation, ask your Coverbase representative to turn it on.
</Note>
Inspect signs in to an application your organization runs (your CRM, your HRIS, your identity provider) with a read-only identity, reads the admin console, and records what it saw. An **inspection** takes one application and one internal control set, collects evidence for each control, and, when you ask it to, scores the evidence against the control's expectation. A control that fails becomes a finding on the same Findings page as everything else.
The mistake people make most often is reading progress as a result. "12 of 12 controls finished" says nothing about whether any passed. Read the outcome band and the status badges, not the count.
## Where it lives
**Inspect** in the left navigation opens five tabs: **Overview**, **Inspections**, **Probes**, **Applications** and **Accounts**. **Configuration** at the right of the tab strip opens **Configuration → Inspect**, where identity providers are connected. **Schedules** is a button on the **Inspections** tab, not a tab of its own.
<Frame>
<img alt="The Inspect Overview tab, showing application count tiles, a posture percentage, a What needs you list, a runs gauge and the latest inspections." />
</Frame>
**Overview** is the place to start each week. Pick a **Time window**, then read:
| Section | What it tells you |
| - | - |
| **Applications connected / inspected / Never inspected / Applications with connection issues** | How much of your estate Inspect can reach, and how much of it has been looked at. |
| **Posture** | The latest scored inspection, averaged across the applications that have one. **No inspection has scored yet** until an Evaluate run completes. |
| **What needs you** | Applications that cannot sign in (**Fix sign-in**), overdue findings (**Review**), inspections that did not finish (**Open**), and applications never inspected (**Inspect**). |
| **Runs** | Failed, partial and completed inspections in the window. |
| **Latest Inspections** and **Leaderboard** | The most recent runs, and which applications raised the most issues. |
## Connecting an application
Inspect needs two things from an application: a way to sign in, and a **Platform** so it knows which documentation and API catalog to plan from. There are two routes in.
<Tabs>
<Tab title="Through an identity provider">
Go to **Configuration → Inspect**. Each provider card reads **Connected**, **Needs verification**, **Connection error** or **Not connected**, and shows how many applications are **added to Inspect** against how many are **available** in the provider.
<Steps>
<Step title="Okta">
**Connect Okta** walks through **App details** (your Okta org URL and the Client ID of an API Services app you create for Coverbase Inspect), **Configure the Okta connection** (add the Coverbase JWKS URL as the app's public key, grant a Read-only Administrator role for inventory, and grant the Organization Administrator and Application Administrator roles that let Coverbase create the inspection identity), then **Choose applications to add**.
Run **Sync from Okta** to pull users, applications and assignments. When you add applications, tick the approval box: Coverbase provisions a dedicated read-only inspection identity in Okta and assigns it only the applications you selected. Afterwards, **Sign in to Okta** under **Okta sign-in** so the identity has a live session. Its status reads **Not signed in**, **Sign-in started**, **Signed in**, **Sign-in expired** or **Sign-in failed**.
</Step>
<Step title="Microsoft Entra">
**Connect Microsoft Entra** follows the same shape: **App details** for an application you register in your tenant, **Configure the Entra connection** to verify the Graph permissions, **Sync and select applications**, then **Prepare applications for inspection**. An Entra application without SAML or OIDC single sign-on shows as **Blocked** in the applications list, because Inspect has no way to sign in to it.
</Step>
<Step title="Google OAuth">
**Google OAuth** stores the Google account email and password Inspect signs in with, plus an optional TOTP secret. Applications that use Google sign-in are added directly (next tab) and pick up these credentials. **Run test inspection** checks that the sign-in works before you rely on it.
</Step>
</Steps>
</Tab>
<Tab title="Directly">
On **Applications**, click **Add Applications**. Choose a **Sign-in method**: **URL + password** for a custom application with its own login page, or **Google OAuth** for one behind Google sign-in. Fill in **Application name**, the **Login URL** (or **Application / SSO URL** for Google), and the **Platform**.
<Warning>
An application with **No platform** can be signed in to but never planned, so no control set can run against it. Choose the platform when you add the application. The **Directory platform** field in the application drawer can be changed later, but the drawer reminds you to **Rebuild attribution** on **Accounts** afterwards.
</Warning>
</Tab>
</Tabs>
<Frame>
<img alt="The Inspect Applications tab, listing applications with Source, Sign-in, Users, Status, Last synced and Last Inspected columns and an Add Applications button." />
</Frame>
### Reading the applications list
| Column | What it shows |
| - | - |
| **Source** | **Okta**, **Entra** or **Added directly**. |
| **Sign-in** | **URL + password**, **Okta application**, **Entra application** or **Google OAuth**. A discovered application that has not been added shows the provider's sign-on protocol instead. |
| **Users** | Assigned users from the provider sync. **Not synced yet** until the sync reaches that application. |
| **Status** | **Added** (Inspect can run against it), **Not added** (discovered by a provider but not yet in Inspect), **Blocked** (cannot be inspected; hover for the reason), **Archived**. |
| **Last synced** and **Last Inspected** | **Never inspected** until the first run. |
Search, filter by source or status, and select rows to **Add**, **Archive**, **Unarchive** or **Find vendor matches** in bulk. The last one links each application to the vendor record it belongs to, so internal and third-party evidence sit on the same vendor.
Click a row to open the drawer. **Summary** holds the login URL, status and a **Vendor** link. **Users** lists the assigned users, with **Admin** where the provider profile names an admin role. **Factors** manages verification factors for the inspection identity. **API Settings** holds the **API origin**, credentials and request parameters that API-based evidence needs; identity provider access does not establish API access, so an application can be signed in and still need this tab filled in. **Inspection readiness** at the foot of the drawer links to **Review readiness**, which opens the inspection setup with this application selected.
## Running an inspection
<Frame>
<img alt="The New inspection setup panel with an application and control set chosen, the Evaluate purpose selected, and a list of controls grouped into Ready, Preparing, Not prepared and Blocked." />
</Frame>
<Steps>
<Step title="Choose what to inspect">
On **Inspections**, click **New Inspection**. Pick an **Application** and a **Control set**. If the application has no control sets yet, **Add Starter Controls** forks a starter set so there is something to run. The full set of internal templates lives in the [Internal Controls Library](/control-library), reached from **Controls → Internal Controls → Internal Controls Library**; a forked template is an ordinary control set you can edit.
</Step>
<Step title="Choose a purpose">
| Purpose | What it does |
| - | - |
| **Evaluate** | Scores each control against its expectation and your scale. The only purpose that produces evaluations, and therefore findings. |
| **Explore** | Collects evidence without scoring it. Use it first against an unfamiliar application to learn what Inspect can reach. |
| **Drift** | Compares against an earlier inspection. **Compare against** lists earlier runs that **Succeeded** or **Partially succeeded** and share the same evidence contract. **No earlier inspection qualifies as a baseline** means you need a completed run first. |
Evaluate needs a scale with an active level on the control set. Without one the launch is refused with **None of the selected controls can be evaluated. Apply a scale with an active level, or choose Explore.**
</Step>
<Step title="Decide on browser evidence">
**Browser evidence** lets Inspect sign in and read pages when the documentation points there. Leave it off and only API methods run; the panel tells you how many controls that holds back (**Allowing browser evidence releases N controls**).
</Step>
<Step title="Get the plans ready">
Every control needs a **plan**: what evidence to collect and how. The list groups controls into **Ready**, **Preparing**, **Not prepared** and **Blocked**. Click **Prepare Plans** for the unprepared ones and wait; a blocker names what is missing (no platform, API origin or credentials not configured, plan preparation failed). **Recheck readiness** re-reads the configuration after you fix something.
</Step>
<Step title="Launch">
**Launch Inspection** starts everything that is ready. If only some controls are ready the button says so: **X of Y controls will run. The rest will be recorded as not planned.** Those controls end as **Not planned** rather than silently dropped.
</Step>
</Steps>
## Reading an inspection
The **Inspections** list shows **Application**, **Initiated**, **Status**, **Purpose**, **Control set**, **Controls finished**, **Outcomes**, **Score**, **Findings** and **Channel** (**API** or **Browser**). The default view, **Inspection runs**, hides probe runs; **All inspections** includes them. Open a row to read it.
### Statuses
An inspection carries one status; each control inside it carries its own.
| Inspection status | Meaning |
| - | - |
| **Created** | Queued, nothing has started. |
| **Running** | At least one control is still collecting. |
| **Succeeded** | Every control finished. |
| **Partial** | Some controls finished and some did not. |
| **Blocked** | Stopped waiting on something you can fix: a sign-in refresh or configuration. Retrying resumes it. |
| **Failed** | Stopped without a result. |
| Control badge | Meaning |
| - | - |
| **Inspecting** | Collecting evidence. **Refreshing sign-in** replaces it while Inspect renews the session. |
| **Completed** | All evidence collected. |
| **Partial** | Some evidence collected, some not. Final. |
| **Action needed** | Blocked. **Retry** resumes it once the cause is fixed. |
| **Not planned** | The control had no plan when the inspection launched. It never ran. |
| **Failed** | Collection stopped with an error. |
<Warning>
A control can finish and still not pass. **How the controls turned out** is the band that matters: **with issues**, **no issues**, **not scored**, **collected** (Explore and Drift only), **no evidence**, **not planned** and **still running**. Click a segment to filter the list to it. **What needs you** under the band lists the controls that raised issues, finished without a score, collected nothing, or had no plan.
</Warning>
### Inside a control
Click a control to open its workspace. A control from a framework-derived set, such as **CIS Controls v8.1 SaaS Baseline**, shows its framework references as badges under its expectation: the CIS safeguard it derives from and the NIST SP 800-53 controls mapped to it. **Evaluation** shows the level the control landed on and the **Justification** written from the evidence; **This control has not been evaluated yet** and **This control could not be fully evaluated** are the two states short of a verdict. **Observations** lists each evidence key with its records, where it was **Collected from**, the screenshot captures, and **Watch replay** for the browser session. **Activity** is the event log.
Each observation carries a status, and an absent one is reported rather than skipped:
| Observation status | Meaning |
| - | - |
| **Observed** | Collected. |
| **Sign-in needed** | The application asked for a sign-in the stored credentials could not satisfy. |
| **Access denied** | Signed in, but the identity is not allowed to see this evidence. |
| **Not supported** | The application does not expose this evidence in a readable form. |
| **Inconclusive** | Reachable, but it did not answer the requirement. |
| **Failed** | Collection stopped before capture. |
Row actions: **Retry** on a failed or blocked control, **Rerun** on a finished one, **Rerun with updated control** after you edit the control (a new plan is prepared first), and **Cancel**. Select several rows to retry, rerun or cancel together. At the top of the page, **Actions → Archive** removes the inspection from the list, **Cancel Inspection** stops a running one, and **Create schedule** turns this application and control set into a monthly run.
### Drift between runs
A Drift inspection collects the same evidence as its reference and reports what moved. The header links to **View reference inspection**. Each control lands in one state:
| State | Meaning |
| - | - |
| **Matches reference** | Every record matches. Nothing changed. |
| **Changed · Judging** | Something moved; Inspect is deciding whether it matters. |
| **Changed · Material** | The change matters. Treat it like an issue. |
| **Changed · Immaterial** | A change that does not affect the control (a renamed label, reordering). |
| **Changed · Unclear** | Inspect reached a verdict of "cannot tell". Read the diff yourself. |
| **Changed · Not judged** | The judging attempt did not finish. **Re-run** the control to try again. |
| **Can't compare** | The control now collects different evidence than the reference did. |
| **No reference evidence** | The reference run collected nothing for this control. |
| **Nothing collected** | This run collected nothing for this control. |
| **Not compared** | The control stopped before anything could be compared. |
| **Waiting for evidence** | Still collecting. |
The comparison panel shows **Reference** beside **This inspection**, marks each record **Changed**, **Added** or **Removed**, and hides unchanged records behind **Show N unchanged records**. If a requirement does not say which fields identify a record, an edited record appears as one removed and one added; the panel says so. Editing a control changes what it collects, which is why **Can't compare** appears after a control edit: take a fresh Evaluate run as the new baseline.
## From an issue to a finding
Only **Evaluate** inspections produce evaluations. On a control whose evaluation raised an issue, **Create Finding** in the **Evaluation** panel creates a finding with the control's expectation as its title and the evaluation attached as its source. Clicking again returns the same finding rather than a duplicate; the button then reads **View Finding**. Coverbase drafts remediation guidance for the finding from the evidence the run collected, so each step can be checked against an observation.
From there it is an ordinary finding. On the **Findings** page, filter **Source** by **Inspect evaluation** to see only these. Assign an owner and due date, route it with the same workflows as third-party findings (see [Workflow templates](/user-guides/workflow-templates)), and it counts in the same dashboards (see the [Dashboard library](/user-guides/dashboard-library)). Overdue internal findings surface back on the Inspect **Overview** under **What needs you**. The Risk module can also take **Inspect** as a signal source, reading evaluations marked as issues on internal control sets.
## Plans and plan versions
A plan is what Inspect prepared for one control on one platform: each **Requirement** with its question, **Comparison focus**, **Observation contract** (what fields to record and how many records to expect) and **Evidence methods** (**Browser**, **REST**, **GraphQL**, **Query** or **Metadata**), plus the **Documented destination**, **What to record** and a **Suggested route**. Reach it with **Review Plan** in the inspection setup or **View plan** from a control.
Plans are immutable. **Edit plan** does not change the plan that ran; **Publish new version** creates the next version and marks the old one superseded. Inspections already running keep the version they started with.
| You can edit | You cannot edit |
| - | - |
| Plan summary, each requirement's question and comparison focus, field labels and descriptions, method titles, browser instructions and the suggested route | Which fields a requirement records, evidence keys, and the body of any API request (**Coverbase composes this API request. Only its title can be changed.**) |
**Check changes** validates before you publish. A refusal names what was wrong: an empty field, an uneditable part of the plan, a route hint with characters other than letters, numbers, hyphens and underscores, or **This plan changed while you were editing**, which means someone else published first; reload and reapply.
Two rules about whose plan it is:
* **Coverbase maintains this plan. Editing it saves your organization's own copy.** A public plan stays as it is for everyone else, and your copy starts at version 1. From then on your organization sees its own plan, not Coverbase's later improvements to the public one.
* **To edit this Coverbase plan, open it from one of your organization's controls.** Editing needs a control in your organization to hang the copy on.
**Versions** lists every version with **Latest** on the one that runs now; only that one can be edited. Editing requires the integration update permission, otherwise **You don't have permission to edit plans**.
## Probes
An inspection evaluates a control set once. A **probe** answers one small question on a cadence: is MFA still enforced, did the nightly export land, does this record show the status we expect. Probes sit on their own tab and their runs appear in **Inspections** under the **All inspections** view.
<Steps>
<Step title="Describe it">
On **Probes**, click **New probe**. Give it a **Name**, pick an **Application**, and answer **What should this probe observe?** in plain language, naming the view or record and the facts to collect. Click **Prepare probe**.
</Step>
<Step title="Review the procedure">
Inspect turns the description into **Checkpoints** that run in order on one browser journey. Each checkpoint lists the **Evidence to Collect**, its **Collection method** (**Browser** or **API**), and an optional **Expectation**: a **Field**, a **Comparison** (**Equals**, **Greater than**, **At least**, **Less than**, **At most**, **Is recorded**), an **Expected value**, and whether it **Applies To** **All records** or **Any record**. A checkpoint with no expectation reads **Data collection only** and contributes no verdict. **On Failure** decides whether the run should **Continue to next checkpoint** or **Stop remaining checkpoints**. Reorder checkpoints, or click **Prepare a new procedure** to start over.
</Step>
<Step title="Run it once">
**Save and run** (or **Save probe**, then **Run now**) executes the procedure once so you can check each checkpoint before anything repeats. A probe that has not been run shows **In preparation**.
</Step>
<Step title="Enable it">
Choose a **Frequency** (**Every 15 minutes**, **Every hour**, **Every 6 hours** or **Every day**) and click **Enable probe**. **Pause** keeps the run history and stops scheduled runs.
</Step>
</Steps>
Reading a run: **Progress** is **Queued**, **Running**, **Completed**, **Partially completed** or **Run failed**. **Expectation** is **Met expectation**, **Did not meet expectation**, **Could not determine** or **Not evaluated**. Each checkpoint reads **Pending**, **Completed**, **Failed** or **Not Reached**; a checkpoint after a stopping failure is **Not Reached**, so an interrupted run still reads as exactly the prefix it finished. **Recent Scheduled Attempts** shows every occasion the schedule tried to start a run, including the ones that did not: **Accepted**, **Blocked**, **Previous run still active** or **Could not start**.
**Revise procedure** publishes a new version of the procedure; earlier runs keep their original meaning. **Save as reusable definition** puts the procedure in a library so another application can run it: open the definition and **Add schedule** for each application.
## Schedules
A schedule reruns an application and control set on a calendar day every month, with no one launching it. Open **Inspections → Schedules**, then **New schedule**: choose the **Application**, **Control set**, **Purpose**, whether to **Allow browser evidence**, and the **Day of month**. **Create schedule** on a finished inspection pre-fills the same dialog. A **Drift** schedule compares each run against the latest completed inspection of that application that ran the same control set, so run one before its first scheduled date.
Each row shows **Cadence** (**Monthly on the 15th**), **Next run**, **Last run** and a **Status** of **Active** or **Paused**. **Actions** offers **Edit schedule**, **Pause**, **Resume** and **Stop repeating**; the last one keeps past runs in the inspections list and runs nothing further.
Before each run Inspect checks sign-in and plan readiness. A run that cannot start is recorded as a missed check and the next occurrence still goes ahead. The inspection page names the cause:
| Missed check | Fix |
| - | - |
| **Inspect could not sign in** | The inspection identity's session is stale. **Run now** to refresh it, or wait for the next scheduled run. |
| **The controls were not ready** | Prepare the plans for this application, then **Prepare and run**. |
| **No control could be scored** | Apply a scale to the control set. |
| **The owner lost permission to run inspections** | Restore the owner's integration permission, or have someone else create the schedule. Scheduled runs execute as the person who created or last resumed the schedule. |
| **The application was unavailable** | **Configure application**, then run. |
| **No finished inspection of this application ran these controls** | A **Drift** schedule has no baseline yet. Run an inspection of the application with the same control set; the next scheduled check compares against it. |
<Note>
A monthly schedule that outlives its application keeps running until you pause or stop it. Archiving the application does not stop the schedule.
</Note>
## The Accounts directory
**Accounts** is what the provider syncs and the inspections observe, joined into one directory: a person or service identity, the application accounts that belong to it, and the evidence attributed to each account. It fills after the first Okta or Entra sync (**Accounts appear once the sync finishes**) and refreshes after every inspection.
Built-in views: **Accounts & evidence** (the default: identities with at least one account), **All identities**, **Guests**, **Admin observed**, **Observed evidence** and **Needs attribution**. Save your own on top of any of them.
Expand an identity to see its **Application accounts**. Each account states how it was tied to the identity:
| Basis | Meaning |
| - | - |
| **Directory assignment** | Matched to the provider's assignment for this application. |
| **Email match** | The observed email matches this identity. A separate application account; the match does not prove an IdP assignment or SSO enforcement. |
| **Observed only** | Known only from collected evidence. No directory assignment or confirmed owner. |
| **Needs attribution** | Identifiers match several possible owners. Nothing is asserted. |
**Admin observed** means an attributed observation once showed admin privileges on that account. It is historical, not a claim about current access. **Admin privilege hint** is weaker still: the provider's assignment profile names an admin role, and no inspection has verified the application honors it. **Latest observed admin state** reads the most recent record: **Admin**, **Not admin**, or **Unknown** when the record carried no privilege attributes.
<Warning>
Absence of evidence is never a negative claim here. An account with no attributed evidence has not been shown to be safe, and an account without an IdP assignment is not by itself an SSO bypass. Attribution covers a bounded window of recent observations.
</Warning>
**Rebuild attribution** re-derives every account link from the current provider inventory and observations. Use it after changing an application's platform or when the page says accounts need review.
## Who can do what
Inspect is switched on per organization. Within it, access follows the **integration** permission described in [Permissions and roles](/user-guides/permissions-and-roles):
| To do this | You need |
| - | - |
| See the Inspect tabs, inspections, plans, probes, schedules and the Accounts directory | Read access to integrations |
| Launch an inspection, run a probe, enable or resume a schedule | Run access to integrations |
| Connect a provider, add or edit applications, edit plans, prepare or pause probes, create or edit schedules | Update access to integrations |
| **Create Finding** from an evaluation | Create access to findings |
## Notifications
Inspect sends three emails to the person who started an inspection, or, for a scheduled run, to the schedule's owner. Each is on by default and can be turned off under the **Inspect** category in your notification settings (see [Email notifications](/user-guides/email-notifications)).
| Notification | When |
| - | - |
| **Inspection found an issue** | An **Evaluate** run finds an issue on a control whose previous result on that application was not already an issue. The email names the application, the control, the level it landed on and an excerpt of the justification. |
| **Inspection found a material change** | A **Drift** run judges a change to a control's evidence **Material**, with a before and after excerpt. |
| **Inspection needs attention** | The inspection ends **Blocked** or **Failed**. It says how many controls were blocked, failed or not planned. |
Alerts from one inspection are gathered into a single email every few minutes rather than sent one per control, and **Open inspection** takes you to the page. Findings created from inspections follow the ordinary finding notifications.
## Troubleshooting
| What you see | What is happening |
| - | - |
| **Inspect** is missing from the left navigation | The module is not enabled for your organization, or your role has no integration access. |
| **Setup access is required** on the Applications tab | You can see Inspect but cannot connect a source. Ask an administrator with Inspect or External Integrations access. |
| An application is **Blocked** | Inspect has no supported way to sign in. For Entra, SAML or OIDC single sign-on is not configured on that application. Hover the badge for the provider's reason. |
| **This application has no platform, so Inspect has nothing to prepare plans from** | The application was added without a **Platform**. Set one in the drawer, then **Prepare Plans**. |
| **Needs API evidence, which Inspect can't collect yet** | The control's plan only has an API method Inspect cannot run here. Remove the control from the set, or configure **API Settings** on the application. |
| Controls end **Not planned** | They had no plan when you launched. Prepare their plans and **Rerun** them. |
| Observations read **Sign-in needed** | The stored session expired. For Okta, **Sign in again** under **Okta sign-in**; for a direct application, check the saved credentials. Then **Retry** the control. |
| Drift shows **Can't compare** or **Changed · Not judged** | The control was edited after the reference run, or the judging attempt timed out. Take a new Evaluate run as the baseline, or **Rerun** the control. |
| **No earlier inspection qualifies as a baseline** | Drift needs a **Succeeded** or **Partially succeeded** run of the same application and control set. Run Evaluate or Explore first. |
| **This plan changed while you were editing** | Someone published a version after you opened the editor. Reload, then reapply your edits. |
| A scheduled run is missing | Open the schedule's latest inspection; the missed-check banner names the reason (sign-in, plans, scale, owner permission, or an unavailable application). |
| Accounts shows **Sync complete · building accounts…** for a long time | Attribution is rebuilding one application at a time. Large directories finish over several runs. Reload later. |
## Related
<CardGroup>
<Card title="Internal control monitoring" icon="building-shield" href="/products/internal-controls-monitoring">
What the module is for, and how internal and third-party risk share one model.
</Card>
<Card title="Control Set library" icon="shield-check" href="/control-library">
The internal control sets Inspect evaluates against, with counts and sources.
</Card>
<Card title="Findings Manager" icon="triangle-exclamation" href="/products/findings-manager">
Where a finding created from an inspection goes next.
</Card>
<Card title="Permissions and roles" icon="user-lock" href="/user-guides/permissions-and-roles">
The integration and finding permissions this guide refers to.
</Card>
</CardGroup>
# The IRQ library
Source: https://docs.coverbase.com/user-guides/irq-library
The six inherent risk questionnaires Coverbase ships: every question each one asks, how the score is calculated, and how to pick and tailor the right starting point.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. Read it when you are choosing which packaged inherent risk questionnaire to start from, or when you want to see exactly what a template asks before you send it.
</Info>
An inherent risk questionnaire (IRQ) rates a third party *before* any of their controls are taken into account. Its score decides how much due diligence the relationship earns and how often it comes back for reassessment, so it is short: the longest template here is fifteen questions, and the shortest takes about a minute.
The **IRQ library** gives you six of them ready to use. Open it from the **IRQ Library** button at the top right of **Configuration → Questionnaires → Inherent Risk**, browse by category, and copy the one you want.
<Note>
Copying a template produces an ordinary questionnaire you own and can edit: question wording, options, weights, reviewers, everything. Nothing syncs back: later changes to the Coverbase template do not reach your copy, and your edits never leave your workspace.
</Note>
## What ships
| Template | Category | Questions | For |
| - | - | -: | - |
| **Standard Inherent Risk Questionnaire** | General | 15 | Any third party, any industry |
| **Inherent Risk Quick Triage** | General | 6 | Self-service intake and fast-track approvals |
| **Financial Services Inherent Risk** | Financial | 13 | Banks, credit unions, insurers, fintechs |
| **Healthcare & Life Sciences Inherent Risk** | Healthcare | 13 | Providers, payers, digital health, life sciences |
| **AI & Emerging Tech Inherent Risk** | AI & Emerging Tech | 12 | Any vendor whose product embeds AI |
| **Data Privacy Inherent Risk** | Compliance | 10 | Processors and controllers handling personal data |
## Choosing a starting point
Pick by **what the engagement does to your risk**, not by the industry you are in. A hospital buying a marketing analytics tool wants the Data Privacy set, not the Healthcare one, unless that tool will touch patient records.
<CardGroup>
<Card title="Start with Standard" icon="scale-balanced">
It covers data, access, criticality, spend, geography and subcontracting without assuming anything about your sector.
</Card>
<Card title="Add Quick Triage alongside it" icon="bolt">
Point self-service intake at Quick Triage and reserve the longer templates for the vendors triage flags. Most requests never need fifteen questions.
</Card>
<Card title="Use a sector template when a regulator is watching" icon="landmark">
Financial Services and Healthcare exist because examiners expect specific determinations (critical activity, business associate status) that a generic questionnaire never asks for.
</Card>
<Card title="Run AI & Emerging Tech as a second pass" icon="microchip">
It answers a different question from the others: not how much of your data is exposed, but what the system decides on its own. Pair it with whichever template fits the underlying purchase.
</Card>
</CardGroup>
## Every template in detail
<AccordionGroup>
<Accordion title="Standard Inherent Risk Questionnaire · 15 questions · General" icon="scale-balanced">
The industry-agnostic default. It covers data sensitivity and volume, network access, business criticality, customer contact, contract spend, regulatory exposure, offshoring, subcontracting and replaceability.
**Engagement Overview** *(no risk domain; context only, unscored)*
1. Describe the product or service the third party will provide. *(free text)*
2. Who is the internal relationship or business owner for this engagement? *(contacts)*
**Data Access and Sensitivity** *(Cybersecurity)*
3. Will the third party access, store, transmit or process any of our data?
4. What is the most sensitive classification of data involved? Options: Public or de-identified · Private · Confidential · Restricted
5. How many records will the third party access, store, transmit or process in aggregate? Options: five bands from under 1,000 to 500,000 or more
6. Will the third party have access to our networks or internal systems? Options: via their own equipment · via company equipment or VDI · no
7. Is this a hosted or cloud-delivered solution?
**Business Impact** *(no risk domain)*
8. How critical is this product or service to the business? Options: High, unrecoverable process · Medium, recoverable with minor impact · Low
9. Does the third party have direct or indirect contact with our customers?
10. Does the third party support our critical infrastructure (software, hardware, data center or network connectivity)?
11. How long would it take to replace this third party if needed? Options: over 12 months · 6-12 months · under 6 months
12. What is the expected spend over the life of the contract? Options: six bands from under US$5,000 to over US$1,000,000
**Regulatory and Geographic Exposure** *(Compliance)*
13. Does this relationship present a regulatory risk? Options: Yes · Unknown · No
14. Is any aspect of this product or service, including subcontracted work, performed offshore? Options: offshore with offshore data · offshore with onshore data · no
15. Does the third party rely on a material subcontractor for any part of the product or service?
**Heaviest weights:** offshore processing and contract spend, each up to 20 points. **No score floors.** The answers alone set the score.
**Typical use:** New vendor intake triage; determining due diligence depth; setting reassessment cadence; annual re-tiering.
</Accordion>
<Accordion title="Inherent Risk Quick Triage · 6 questions · General" icon="bolt">
Written for a requester who is not a risk professional, so a software purchase request can be routed in under a minute. Six questions, one section, no free text.
1. What is the most sensitive data this vendor will handle? Options: Regulated or restricted (health, financial, government ID) · Confidential business or customer records · Internal only · Public only · None
2. Will the vendor connect to our systems, networks or accounts? Options: privileged/admin/write · read-only or limited integration · no
3. If this vendor went down for a week, what would happen? Options: could not serve customers · a team significantly degraded · little or no impact
4. What is the expected annual spend? Options: over US$250,000 · US$25,000-250,000 · under US\$25,000
5. Does the engagement fall under a regulation such as GDPR, HIPAA, PCI DSS, GLBA or SOX? Options: Yes · Unknown · No
6. Will the vendor interact with our customers or process customer data? Options: directly · indirectly · no
**No score floors.** Every question is weighted evenly enough that no single answer dominates, which is what you want from a form a requester fills in about themselves.
**Typical use:** Self-service vendor intake; fast-track approval for low-risk vendors; pre-screening before a full questionnaire.
</Accordion>
<Accordion title="Financial Services Inherent Risk · 13 questions · Financial" icon="landmark">
Built around the pivotal determination in the [2023 Interagency Guidance on Third-Party Relationships](https://www.federalregister.gov/d/2023-12340): whether the relationship supports a *critical activity*.
**Criticality and Regulatory Designation** *(Compliance)*
1. Does this relationship support a critical activity, meaning one that could cause significant risk if the third party fails to perform, significant customer impact, or significant impact on operations? **Yes floors the score at 70.**
2. Which regulatory regimes apply to this engagement? *(select multiple)* Options: GLBA / Regulation P · BSA / AML / OFAC · SOX · PCI DSS · SEC / FINRA · state money transmission licensing
3. Will the third party's outputs feed regulatory reporting or the financial statements?
**Consumer Data and Funds** *(Financial)*
4. Will the third party access, store or process nonpublic personal information (NPI) under GLBA? Options: over 100,000 consumers · under 100,000 · no
5. Will the third party hold, move or have authority over customer funds? Options: with discretion · pass-through only · no
6. Will the third party perform a consumer-facing activity subject to UDAAP or fair lending oversight?
7. Does the third party perform or support BSA/AML, sanctions screening or KYC obligations? Options: performs on our behalf · supporting data or tooling · no
8. Does the third party have access to core banking, payment, trading or ledger systems? Options: transactional/write · read-only · no
**Resilience and Concentration** *(no risk domain)*
9. What is the maximum tolerable downtime for this service? Options: under 4 hours · 4-24 hours · 1-3 days · over 3 days
10. Does the third party rely on material subcontractors (fourth parties) to deliver the service? Options: yes, unidentified · yes, disclosed · no
11. How readily could this third party be replaced?
12. Where will our data be stored or processed relative to our primary regulator's jurisdiction?
13. What is the expected spend over the life of the contract?
Because the critical-activity answer sets a floor, a critical relationship cannot be diluted into a low rating by benign answers elsewhere, which is the failure mode an examiner looks for.
**Typical use:** Bank and credit union vendor onboarding; critical activity designation; examiner-ready tiering; fintech partner due diligence.
</Accordion>
<Accordion title="Healthcare & Life Sciences Inherent Risk · 13 questions · Healthcare" icon="stethoscope">
Leads with business associate status under [HIPAA](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164), then works outward through data, clinical proximity and supply chain.
**Protected Health Information** *(Compliance)*
1. Will the third party create, receive, maintain or transmit protected health information on our behalf, making it a business associate? **Yes floors the score at 60.**
2. How many patient or member records will the third party handle? Options: five bands from none to 100,000 or more
3. Which categories of sensitive data are involved? *(select multiple)* Options: PHI · substance use disorder records (42 CFR Part 2) · behavioral or mental health · genetic or genomic · payment card or billing · de-identified only
4. Will PHI be stored or processed outside the country of collection?
**Clinical and Patient Safety Impact** *(no risk domain)*
5. Does the service touch clinical care delivery or patient safety? Options: informs diagnosis or treatment · supports clinical workflow · administrative only
6. Is the product a regulated medical device or software as a medical device (SaMD)? Options: FDA-regulated or CE-marked · under evaluation · no
7. Will the third party have access to EHR or EMR systems? Options: write or integration · read-only · no
8. Will the third party interact directly with patients or research subjects?
9. What is the maximum tolerable downtime for this service?
**Regulatory and Supply Chain** *(Compliance)*
10. Which regulatory regimes apply to this engagement? *(select multiple)* Options: HIPAA / HITECH · 42 CFR Part 2 · FDA 21 CFR Part 11 · GxP (GCP, GLP, GMP) · state health privacy laws
11. Does the third party subcontract any part of the service? Options: subcontractors handle PHI · subcontractors without PHI access · no
12. How long would it take to replace this third party if needed?
13. What is the expected spend over the life of the contract?
**Typical use:** Business associate triage; digital health vendor onboarding; clinical system procurement; life sciences supplier qualification.
</Accordion>
<Accordion title="AI & Emerging Tech Inherent Risk · 12 questions · AI & Emerging Tech" icon="microchip">
For any vendor whose product embeds AI, whether or not AI is what you are buying. Aligned with the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) and the [EU AI Act](https://artificialintelligenceact.eu/).
**AI Footprint** *(Cybersecurity)*
1. What role does AI play in the product or service? Options: core · optional or embedded feature · none
2. Will our data be used to train, fine-tune or otherwise improve the vendor's models? Options: across their customer base · unknown · within our tenant only · contractually prohibited
3. What is the most sensitive data that will be sent to the model?
4. Does the vendor disclose which foundation models and AI subprocessors it relies on? Options: not disclosed · partially · fully disclosed and contractually committed
**Autonomy and Consequence** *(no risk domain)*
5. What degree of autonomy does the system have? Options: consequential actions without human review · actions subject to approval · recommends only · informational output only
6. Will the system have access to our systems, tools or credentials, for example through agentic tool use or an API integration? Options: write or transactional · read-only · no
7. Does the system make or materially inform decisions about people, such as hiring, credit, insurance, healthcare, housing or education? **Yes floors the score at 65.**
8. Is AI-generated output shown to customers or the public? Options: without human review · with review · internal only
**Governance and Regulatory Exposure** *(Compliance)*
9. Under the EU AI Act, how would this system most likely be classified? Options: prohibited or unclear · high-risk (Annex III) · limited risk with transparency obligations · minimal risk or out of scope
10. Does the vendor maintain an AI governance program, such as documented evaluations, model cards, red-teaming or ISO/IEC 42001 certification?
11. Could the system's output create intellectual property, defamation or copyright exposure?
12. How critical is this AI system to the business?
<Tip>
Question 2 is the one that most often changes a purchase. "Unknown" is weighted almost as heavily as "yes, across the vendor's customer base" on purpose: an unanswered training question is a live exposure, not a neutral one.
</Tip>
**Typical use:** AI vendor onboarding; shadow AI discovery triage; EU AI Act readiness screening; agentic tooling review.
</Accordion>
<Accordion title="Data Privacy Inherent Risk · 10 questions · Compliance" icon="user-shield">
Enough to decide whether a DPIA and a transfer mechanism are needed before the engagement proceeds. Aligned with the [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) and the major US state regimes.
**Processing Role and Data** *(Compliance)*
1. What role will the third party play in processing personal data? Options: joint controller · independent controller · processor on our instructions · no personal data
2. Which categories of personal data are involved? *(select multiple)* Options: contact details and identifiers · financial or payment · location or behavioral tracking · biometric · special category (health, race, religion, union membership, sexual orientation) · children's data
3. How many data subjects are affected? Options: five bands from under 1,000 to over 1,000,000
4. Which privacy regimes apply to this engagement? *(select multiple)* Options: EU GDPR · UK GDPR · CCPA / CPRA · other US state privacy laws · LGPD, PIPEDA, APPI or similar
**Transfers and Secondary Use** *(Compliance)*
5. Will personal data be transferred outside its jurisdiction of collection? Options: no adequacy decision or safeguards · adequacy, SCCs or DPF cover · no transfer
6. Will the third party use personal data for its own purposes, such as analytics, marketing or model training? Options: yes · aggregated or de-identified only · limited to our instructions
7. Will the third party carry out automated decision-making or profiling? Options: with legal or similarly significant effects · profiling without significant effects · no
8. Does the third party engage sub-processors? Options: undisclosed · disclosed with a right to object · no
9. How long will the third party retain personal data? Options: indefinitely or at their discretion · a defined period over three years · no longer than the contract term
10. Does the engagement involve direct marketing, cookies or cross-site tracking on our behalf?
**Typical use:** DPIA screening; sub-processor approval; international transfer review; marketing and adtech vendor triage.
</Accordion>
</AccordionGroup>
## How the score works
Each answer option carries a weight. The inherent risk score is the total of the weights you selected, divided by the highest total those same questions could have produced, expressed as a percentage from 0 to 100. That score then maps to an inherent risk level through the scale configured under **Configuration → Scales → Risk**.
Two things follow from that normalization:
* **Weights are relative.** They only have to be right against each other, so you can add, remove or reword questions without rebalancing the whole questionnaire.
* **Context questions are free.** Free-text, contact, country and currency questions never affect the score, so you can ask for the business owner or a service description without skewing the rating.
Some answers set a **score floor** instead of adding to the total. Three templates use one:
| Template | The question | Floor |
| - | - | -: |
| Financial Services | Supports a critical activity | 70 |
| AI & Emerging Tech | Makes or materially informs decisions about people | 65 |
| Healthcare & Life Sciences | Business associate under HIPAA | 60 |
When one of those answers is picked, the questionnaire cannot score below that floor no matter how the other questions are answered.
Sections are mapped to risk domains (Cybersecurity, Compliance, Financial, Reputational), so a copied template also produces per-domain inherent risk scores alongside the overall one. Sections with no domain, such as Business Impact, still count toward the overall score unless you weight your risk domains.
### Weighting risk domains
By default every scoring question counts toward the overall score on equal terms, so a domain's influence is whatever its questions add up to. To make a domain count for a fixed share instead, go to **Configuration → Risk Domains** and fill in **Weight in IRQ score** for the domains you care about. Once any domain carries a weight, the overall score becomes a weighted average of the domain scores:
* Weights are normalized by the total of the domains that scored, so they do not have to add up to 100, and an unanswered domain does not drag the score down.
* Answers in a section with no risk domain, or whose domain has no weight, no longer count. The submission's **How this score was weighted** table names how many answered questions were left out.
* A score floor still applies after the weighting.
Leave every weight empty to keep the unweighted calculation.
## Tailoring your copy
Everything is editable once you have copied a template. The adjustments worth making first:
* **Reword the spend bands** to match your own thresholds and currency. The shipped bands are US dollars and will be wrong for most workspaces.
* **Adjust weights** in the Value column on each option to reflect your risk appetite.
* **Add a score floor** on any option that should guarantee a minimum rating, your own equivalent of the critical-activity question.
* **Delete what you will not act on.** A question whose answer never changes the due diligence you run is a question that costs you response rates.
* **Wire it into intake** from **Actions → Intake Configuration** so new vendor requests are rated automatically.
* **Set risk levels** from **Actions → Configure Risk Levels** to control where the score lands.
## Where to go next
<CardGroup>
<Card title="Requesting a vendor" icon="cart-plus" href="/user-guides/requesting-a-vendor">
How an intake request flows through the questionnaire you wired in, and what the requester sees.
</Card>
<Card title="Running an assessment" icon="clipboard-check" href="/user-guides/running-an-assessment">
What happens after the inherent risk score lands: scoping, sending, and reviewing the control assessment it triggers.
</Card>
<Card title="Zero touch assessments" icon="wand-magic-sparkles" href="/user-guides/zero-touch-assessments">
Letting a low inherent risk score close out due diligence without a human in the loop.
</Card>
<Card title="Admin setup" icon="sliders" href="/user-guides/admin-setup">
Risk scales, risk levels and the configuration the inherent risk score maps into.
</Card>
</CardGroup>
# The issue acceptance chain
Source: https://docs.coverbase.com/user-guides/issue-acceptance-chain
Route a decision to accept a finding's risk through the finding owner, a recommending Risk Group, the deciding TPRM Office and an extended approver: set up routing rules, record each step, decide in bulk, and read the effect on residual risk.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Risk Acceptance Routing** under **Findings Settings** and the **Decision Path** on a finding. It sits beside [Findings and remediation](/user-guides/findings-and-remediation), which covers statuses and vendor commitments, and [Due diligence methods and the portal](/user-guides/due-diligence-methods-and-portal). For what the module is, see [Due diligence](/products/due-diligence#the-acceptance-chain).
</Info>
Without routing, one person with permission to accept risk can accept a finding's risk on their own. Routing rules put a chain in front of that decision: the finding's owner proposes, a Risk Group recommends, the TPRM Office decides, and an acceptance longer than a set number of days needs one more approver.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
The mistake people make most often is trying to set a routed finding to **Risk accepted** directly. Once a rule routes a finding, every path to risk accepted is refused until the chain has approved the acceptance, and the error says so.
## How the chain works
| Step | Who | Can choose |
| - | - | - |
| **Propose** | The finding's owner (its assignee), or anyone who can update the finding | **Accept risk**, **Remediate** or **Escalate** |
| **Recommend** | The rule's **Recommending Group**, if the rule names one | **Accept risk**, **Remediate** or **Escalate** |
| **Decide** | The rule's **Deciding Group**, or anyone allowed to accept risk if the rule names none | **Accept risk** or **Remediate** |
| **Approve** | The rule's **Approver Beyond That**, only when the acceptance runs longer than the rule's days | **Approve** or **Reject** |
* **Escalate** skips the recommendation and goes straight to the decision.
* The deciding group can decide at any point, before or against the earlier steps. That is recorded as an overrule.
* Accepting risk always needs an end date, no more than 366 days from today.
* A rejected extended acceptance goes back to the decision step.
* Group members and the group's lead can act for the group.
Each step records a rationale. The next person in the chain (the group's lead, or the extended approver) is notified, never the person who acted last.
## Step 1: Write routing rules
Open **Configuration**, choose **Findings Settings**, and find **Risk Acceptance Routing**. With no rules, every finding follows the single-approver path.
Click **Add rule**:
1. **Name** the rule, for example "High severity on critical data".
2. Choose the **Severity or Risk Levels** it matches. Leave it empty to match every finding.
3. Choose the **Recommending Group**, or **No recommendation step**.
4. Choose the **Deciding Group**, or **Any risk acceptance approver**.
5. Optionally set **Days** and the **Approver Beyond That**: an acceptance longer than that many days also needs that person.
6. Click **Save rule**.
<Frame>
<img alt="Risk Acceptance Routing table with rule 1 routed to the Privacy Risk Group to recommend, the TPRM Office to decide and Chris Ruiz to sign off past 180 days, and rule 2 Everything else with no recommendation step" />
</Frame>
Rules are checked in order and a finding follows the first one that matches. Use **Move up** and **Move down** to order them, most specific first. Deleting a rule sends its findings to the next rule that matches; decisions already recorded stay on their findings.
## Step 2: Read a finding's path
Open the finding. Three cards explain where it stands:
* **Acceptance Routing** names the matching rule (**Rule 2 of 4**) and who proposes, recommends, decides and approves. **No routing rule matches** means the finding follows the single-approver path.
* **Decision Path** shows each step recorded so far, its outcome and rationale, and the next step, such as **Risk group recommends** or **Sign-off on acceptances over 90 days**.
* **Effect on Risk** shows the vendor's residual risk now, **If closed** and **If accepted**, using the finding's recorded residual risk reduction.
<Frame>
<img alt="Finding page showing Acceptance Routing Rule 1 of 1, Effect on Risk, and a Decision Path with an owner proposal to accept, a Privacy escalation, a TPRM Office overrule to remediate, and Request remediation plan from vendor" />
</Frame>
## Step 3: Record a step
Click the button for your step on the **Decision Path**: **Propose**, **Recommend**, **Decide** (or **Decide now** to overrule), or **Review acceptance**. Choose the **Outcome**, write the **Rationale**, and for an acceptance pick **Accept Until**. Then record it.
With [Teams approvals](/integrations/guides/microsoft-teams#register-the-bot) on, the person or group the chain waits on can also approve or decline the step from a Teams card, with their own Coverbase permissions. A card for a step the chain has already moved past is refused.
If the button is missing, the chain is waiting on someone else: **Waiting on another step. You'll be notified when this finding needs you.**
## Step 4: Apply the acceptance
When the chain approves accepting the risk, click **Apply risk acceptance**. This sets the finding to risk accepted through the ordinary finding update, with an exception that ends on the date the chain approved. An exception cannot outlast that date.
When the outcome is **Remediate**, **Request remediation plan from vendor** asks the vendor for a plan through the portal.
## Decide in bulk
On the **Findings** list, select findings and choose **Record decision**. Pick the **Step** (**Propose**, **Recommend** or **Decide**), the outcome and a rationale, which is recorded on each finding. Turn on **Accept the risk right away on findings this decision fully approves** to apply acceptances in the same action.
Findings that are not at that step, or whose step is not yours, are skipped and stay selected. The summary reports each group, for example "12 findings accepted, 3 need a decision", so you can act on the rest next.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| Setting **Risk accepted** fails with a message that the finding is routed | A rule routes the finding and its chain has not approved accepting the risk. | Work the **Decision Path**, then **Apply risk acceptance**. |
| **Assign this finding so its owner can propose** | The finding has no assignee. | Assign it. |
| **Only the routed Risk Group recommends** | You are not a member or lead of the recommending group. | Ask a member of that group, or add yourself to it. |
| The acceptance is stuck at **Awaiting approval** | It runs past the rule's days and needs the extended approver. | The named approver clicks **Review acceptance**. Or decide again with a shorter **Accept Until**. |
| **Accept Until** rejects the date | The date is in the past or more than 366 days out. | Pick a date within the limit. |
| The exception's end date cannot be changed to a later date | An exception cannot outlast the acceptance the chain approved. | Run the chain again for a longer acceptance. |
| Bulk decision skipped some findings | They were at a different step, or the step was not yours. | They stay selected. Record the step they are at, or ask the right person. |
## Related
<CardGroup>
<Card title="Findings and remediation" icon="flag" href="/user-guides/findings-and-remediation">
Statuses, commitments and verification.
</Card>
<Card title="Due diligence methods and the portal" icon="magnifying-glass-chart" href="/user-guides/due-diligence-methods-and-portal">
Raising a finding on a question.
</Card>
<Card title="Assignment, delegation and out of office" icon="user-clock" href="/user-guides/assignment-and-delegation">
User groups and their leads.
</Card>
<Card title="Findings Manager" icon="flag" href="/products/findings-manager">
Time-bound risk acceptance and remediation.
</Card>
</CardGroup>
# Monitoring plans
Source: https://docs.coverbase.com/user-guides/monitoring-plans
Set the cadence matrix, signal re-timing, pausing statuses and scorecard rubrics, then read an engagement's monitoring plan, edit an activity, keep or revert a signal move, refresh an IRQ and confirm its diff, answer an owner attestation, and score a performance scorecard.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Configuration → Monitoring Plans** and the **Monitoring Plan** and **Scorecard** tabs on an engagement or service. It sits beside [The engagement record](/user-guides/engagement-record) and [Working Radar signals](/user-guides/radar-signals). For what the module is, see [Monitoring plans and scorecards](/products/monitoring-plans).
</Info>
<Note>
Your Coverbase representative turns on the third-party lifecycle features, including monitoring plans, for your organization.
</Note>
Every active engagement gets a monitoring plan: which activities it owes at its tier, who owns each, and when each is next due. A service outside any engagement gets a plan of its own. You set the rules once, and plans follow them.
The mistake people make most often is changing the reassessment interval on the cadence matrix and finding it does not move. The reassessment interval comes from your reassessment rules, and the plan only mirrors it.
## Step 1: Set the methodology
Open **Configuration** and choose **Monitoring Plans**. Changing it needs a role that can change organization settings.
<Steps>
<Step title="Cadence Matrix">
For each tier of your risk scale, set the interval in months for each activity: **IRQ Refresh**, **Performance Scorecard**, **Owner Attestation**, **Evidence Request** and **Contract Review**, and who owns it, the **Transaction Owner** or the **TPRM Office**. 0 means the tier does not need the activity. Until you save, the page shows the default intervals, ranked by tier. **DD Reassessment** reads your reassessment rules and **Continuous Monitoring** is Radar, so neither is set here.
</Step>
<Step title="Methodology">
Choose the **TPRM Office** group (left unset, it is the TPRM Office named under **Configuration → Communications**, then the vendor's risk analysts), the **Upcoming Notice (Days)** before an activity is due, the **Overdue Escalation (Days)** after which the owner and the TPRM Office are escalated to, and the **Low Scorecard Threshold**.
</Step>
<Step title="Signal Re-timing">
Choose **Alerts at or above** a severity, whether **Reassessment triggers** count, how far forward to pull activities (**Due within (days)**), the **Undo window (days)**, and which activities a signal **Re-times**. Signals move plans only while the **Re-time monitoring from feed signals** policy is on in the [Agent Ledger](/user-guides/agent-ledger#step-3-choose-what-agents-may-do). It is off by default, and the page warns when the rule is on but the policy is off.
</Step>
<Step title="Pausing Statuses">
Canceled statuses always pause a plan. Add any other engagement or service status that should, such as On hold. Under **Start Offboarding Moves To**, choose the status an owner's start offboarding answer sets (the first canceled status unless you choose one).
</Step>
<Step title="Scorecard Rubrics">
Click **Add binding** to bind a **Rubric** to a tier (or **Any tier**) and a **Service Category** (or **Any category**), with its **Respondents**. The most specific match wins. With no binding, the default rubric is scored by the owner.
</Step>
</Steps>
Click **Save**. Plans pick up a change on their next re-plan.
<Frame>
<img alt="Monitoring Plans settings page with a cadence matrix of intervals and owners for Critical, High, Medium and Low tiers, methodology fields, signal re-timing set to high alerts and above, pausing statuses and two scorecard rubric bindings" />
</Frame>
## Step 2: Read a plan
Open the engagement (or the service) and choose the **Monitoring Plan** tab. The header says when the plan was generated and why, for example **when the engagement went active** or **at contract execution**. If no plan exists yet, the TPRM Office can click **Generate plan now**.
The timeline shows the next twelve months for each activity, with its owner and interval. Markers read **Done**, **Planned**, **Overdue** or **Moved by a signal**, and **Today** marks the current date. **Continuous Monitoring** reads **Always on** while Radar watches the vendor.
<Frame>
<img alt="Monitoring Plan tab for the Media mix modeling engagement, with a banner saying a security rating drop moved the evidence request to October 29, 2026 and Keep and Revert buttons, a timeline of seven activities, and IRQ Refresh and Owner Attestation cards" />
</Frame>
A service that belongs to a live engagement shows **This service is monitored under its engagement's plan.** with **Open engagement plan**.
## Step 3: Edit an activity
The TPRM Office clicks **Edit plan**, picks the **Activity**, and changes its **Interval (Months)**, **Next Due Date**, **Owner** (a person, or **By role**) or **Enabled**, with a **Reason**. Click **Save**.
An edited activity keeps its interval, owner and due date when the plan is re-planned. Moving the reassessment's due date moves the vendor's reassessment schedule, so the reassessment is created on the new date. A date is never moved inside the window reassessments need to be prepared in.
## Step 4: Keep or revert a signal move
When a Radar alert or a reassessment trigger matches your signal rule, the activities you chose move forward at once, and the plan shows what moved: **IRQ Refresh moved from 12 March to 2 January**, with the signal's source and date. Within the undo window, the TPRM Office clicks **Keep** or **Revert**. Reverting restores each schedule the move changed. A signal moves a plan once, however often it is delivered.
## Step 5: Refresh an IRQ
The Transaction Owner opens the **IRQ Refresh** card and clicks **Refresh IRQ**. The questionnaire opens prefilled from the last approved IRQ, and every answer saves as you go. Change what is no longer true, then **Submit for review**.
The card then shows the diff for the TPRM Office: each answer that changed, before and after, each domain's score and level, **Newly in scope** domains, and the **Engagement Tier** before and after. The TPRM Office clicks **Confirm and re-plan**, or **Confirm and schedule reassessment** when a domain was newly scoped or the tier rose. A reassessment is then raised straight away for the engagement's services. **Withdraw** abandons a refresh before it is confirmed.
The Transaction Owner can refresh the IRQ and answer it without any vendor or questionnaire permission: access comes from owning the engagement.
## Step 6: Answer an owner attestation
When an attestation is due, its owner sees **Is ... still in use?** Answer **Yes, still in use**, or **Start offboarding**. Every answer is logged with the date and user.
**Start offboarding** files an offboarding request with you as the requester and your note as the justification, moves the engagement to its not-in-use status, and pauses the plan. Answering twice never files a second request. A service outside any engagement has no offboarding request.
## Step 7: Score a scorecard
When a scorecard comes due, each respondent is assigned and notified. On the **Scorecard** tab, click **Score now**, score each category (each shows its **Weight**), add **Notes** and **Submit scorecard**.
The tab shows the **Weighted Score** for the period, the change from the previous period, a flag when it is **Below the threshold**, the **Categories and Weights** of the rubric, and **SLA Adherence** from the vendor's SLAs (Met and On track count as adhering). The period closes when every respondent has scored or the escalation window passes.
## Work across plans in the Monitoring workbench
Open **Monitoring** in the left navigation. **Activities** lists every scheduled activity with its engagement or service, owner, due date and status. **Plans** lists every plan with its tier and when it was generated. Search, choose which **Activities**, the **Due** window (**Overdue**, **Next 30 days**, **Next 90 days** or **All**), and **Owned by me**.
Select activities, then:
* **Reschedule**: **Move to a date** or **Shift by days** (a negative number pulls them earlier), with an optional **Note**. Each move is logged as a TPRM Office edit. A reassessment moves its scheduled date too.
* **Send scorecards**: opens each scorecard's current period today and asks its respondents to score.
Up to 20 activities run at once. More run in the background with progress, and the result reads, for example, "18 moved, 2 need attention", listing each with its reason.
## Compare submissions
On the vendor's **Questionnaires** tab, **Compare** shows a finished submission beside the vendor's earlier submission of the same questionnaire: **Domain Scores** before and after (with **Risk rose** where it did), and every answer **Changed**, **Added**, **Removed** or **Unchanged**, with its score. Show only the changes, or all answers.
## Plan history
**Plan History** records everything that happened to a plan: generation, re-plans, every edit with before and after, completions, notices and escalations, signal moves and whether they were kept or reverted, pauses and resumes, attestations, IRQ refreshes, reassessments raised and offboarding requested.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **Monitoring Plan** tab | The third-party lifecycle features are not on for your organization. | Ask your Coverbase representative. |
| **A monitoring plan is generated when the engagement goes active or its contract is executed.** | The engagement has not started yet. | Wait, or click **Generate plan now**. |
| The plan is **Paused** | The engagement or service is in a canceled status, expired, or in one of your pausing statuses. | Move it back to an active status. Due dates shift by the time spent paused. |
| Radar went quiet for a vendor | Every plan for the vendor paused, and no other live engagement needed Radar. | Resume a plan. Radar comes back on where the pause turned it off. |
| The reassessment interval on the matrix cannot be edited | It comes from your reassessment rules. | Change the reassessment rule, or move the reassessment's date with **Edit plan**. |
| A signal moved an activity you did not want moved | Your signal rule re-times that activity. | **Revert** within the undo window, and remove the activity from **Re-times**. |
| Signals never move a plan | The **Re-time monitoring from feed signals** agent policy is off. | Turn it on in the Agent Ledger. Held-back moves are listed there. |
| A bulk reschedule skipped some activities | Each skipped activity was paused, had no date, or would land in the past or inside a reassessment's collection time. | Read the reason on each, and adjust the date. |
| **Generate plan now** is refused for a service | The service belongs to a live engagement. | Use the engagement's plan. |
| No scorecard was issued | No tier requires one, or the activity is not yet within its notice window. | Set a **Performance Scorecard** interval for the tier. |
## Related
<CardGroup>
<Card title="The engagement record" icon="route" href="/user-guides/engagement-record">
The engagement page the plan lives on.
</Card>
<Card title="Working Radar signals" icon="satellite-dish" href="/user-guides/radar-signals">
The alerts that re-time a plan.
</Card>
<Card title="Offboarding and continuity" icon="right-from-bracket" href="/user-guides/offboarding-and-continuity">
What Start offboarding sets in motion.
</Card>
<Card title="Front Door triage" icon="door-open" href="/user-guides/front-door-triage">
Opening an IRQ refresh from a material change.
</Card>
</CardGroup>
# Natural hazard monitoring guide
Source: https://docs.coverbase.com/user-guides/natural-hazard-monitoring
How to watch earthquakes, storms, floods, wildfires and severe weather warnings, and get an alert when one reaches the location of a vendor's site.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the natural hazard sources specifically; for reading and triaging the signals they produce, see the [Radar signals guide](/user-guides/radar-signals). For where your vendors' sites are, see the [Risk geography map](/user-guides/risk-geography-map). For every source Coverbase draws on, see the [source library](/products/source-library).
</Info>
A hazard feed never names your vendor. An earthquake report says "M 6.1, 2 km SW of Sakai, Japan", not "your wafer supplier". Coverbase connects the two through **where your vendors' sites are**: each hazard is turned into an area on the map, and any vendor with a site inside that area is in scope.
The most common reason these sources produce nothing is that the vendor has no located site. Add sites with addresses before you rely on this.
## What Coverbase monitors
The **Natural Hazards** group in the source library holds seven sources.
| Source | Coverage | What it covers | Checked |
| - | - | - | - |
| USGS Earthquakes (M4.5+) | Worldwide | Every earthquake of magnitude 4.5 or more, with depth, PAGER alert level and tsunami flag | Hourly |
| GDACS Disaster Alerts (orange and red) | Worldwide | UN and European Commission alerts for earthquakes, tropical cyclones, floods, volcanoes, droughts and wildfires, with the affected countries | Every 3 hours |
| NASA EONET natural events | Worldwide | Open wildfires, severe storms and their tracks, volcanic eruptions, floods and landslides | Every 3 hours |
| US National Weather Service, severe and extreme alerts | United States | Tornado, severe thunderstorm and hail, flash flood, hurricane, winter storm, extreme heat and fire weather warnings and watches | Every 30 minutes |
| Meteoalarm, Sweden | Sweden | Orange and red warnings from the national weather service | Hourly |
| Meteoalarm, the Netherlands | The Netherlands | Orange and red warnings from the national weather service | Hourly |
| Meteoalarm, Germany | Germany | Orange and red warnings from the national weather service | Hourly |
Each source only collects what is worth reading. Coverbase skips earthquakes below magnitude 4.5, GDACS green alerts, weather service alerts below Severe, and Meteoalarm yellow warnings and warnings that have already expired.
<Note>
Hail has no feed of its own anywhere. It arrives inside US severe thunderstorm warnings and Meteoalarm thunderstorm warnings, which name hail when it is expected.
</Note>
## How a hazard reaches a vendor
Coverbase draws an area for each hazard and checks it against every active site of your active vendors.
| Hazard | The area Coverbase draws |
| - | - |
| Earthquake | A circle around the epicenter, larger for a stronger earthquake: about 30 km at magnitude 4.5, 120 km at 6.0 and 280 km at 7.0 |
| Weather warning with a polygon | The warned polygon, plus a few kilometers around its edge |
| US warning issued by county | Each warned county |
| Meteoalarm warning without a polygon | The warned region, matched by name |
| Storm | The storm's latest positions along its track |
| Wildfire, volcano, flood | A circle around the event |
| GDACS alert for one to three countries | Those countries |
How a site is matched depends on how precisely you have located it:
| Your site has | It matches when |
| - | - |
| An address or coordinates | It falls inside the area, or slightly outside a polygon's edge |
| A city or region but no coordinates yet | A warning names that region |
| Only a country | A GDACS alert names that country |
A located site is judged by distance only. A hurricane in Mexico does not reach a plant in Mexico City only because both are in Mexico. The areas are deliberately generous, because the detector judges how serious the hazard is for the site. The area only decides which vendors it is asked about.
<Tip>
Enter full addresses rather than a country alone. Coverbase converts addresses to coordinates on a schedule, so a site added minutes ago gets its own position shortly after. A site with only a country is reached by very few hazards.
</Tip>
## Step 1. Locate your vendors' sites
Open a vendor and add its sites on the **Locations** card, with a street address or at least a city. The card appears when the Risk module is on. The [Risk geography map](/user-guides/risk-geography-map) shows which sites have been located: a solid dot is a located site, and a country with only a hollow mark holds sites Coverbase cannot place yet.
## Step 2. Turn on the detector
Go to **Configuration → Radar**, open the **Detectors** tab, and click **Add detector → From detector library**. Search for **Natural Hazard Near a Supplier Site** (it sits in the **Geopolitical & External** segment) and click **Configure** to add it and open it for editing, or **Add detector** to add it with its defaults.
Enabling it adds the seven natural hazard sources to your sources where you do not have them already, and scopes the detector to them. You can also add the sources yourself from **Sources → Add source → From Source Library**, in the **Natural Hazards** segment, but nothing alerts until a detector reads them.
<Note>
Only a detector scoped to these sources judges a vendor that a hazard reached through its site. Your other detectors keep reading what names the vendor, so they do not all start evaluating every storm near a supplier.
</Note>
In the editor, check two settings:
* **Sources.** Remove the sources for regions you have no suppliers in. Keeping them costs nothing, but removing them keeps the source list readable.
* **Severity threshold.** The default is Medium. High limits alerts to destructive events at or very near a site, such as a strong shallow earthquake, a hurricane landfall or a red alert.
## Step 3. Check what arrives
Go to **Radar → Signals**. A hazard signal names the sites it reached and how far each one is from the hazard, for example "inside the hazard area, 36 km from its centre". The signal's exposure lists each of those vendors as directly exposed.
How the detector grades a hazard:
| Severity | Typical case |
| - | - |
| High | A destructive hazard at or very near a site: a strong shallow earthquake close to it, a hurricane making landfall over it, a red alert, an observed tornado or a flash flood emergency covering it |
| Medium | A credible threat of disruption: an orange alert or a severe warning covering the site, a moderate earthquake nearby, an active wildfire close to it |
| Low | A plausible but minor effect, and any watch or forecast whose certainty is only "possible" |
| Informational | A hazard unlikely to affect the site, such as light shaking far away or a warning that has already expired |
Triaging what arrives works the same way as any other signal, which the [Radar signals guide](/user-guides/radar-signals) covers. A useful first step on a Medium or High signal is to ask the vendor to confirm the site's status and its continuity plan.
## What to know when reading these signals
**The signal is about a place, not a company.** The source will not mention your vendor. The link is the site, so check that the site is still in use before you act.
**The first report is not revised.** Coverbase reads each earthquake and storm once, when it first appears. A later revision of the magnitude, or a storm that moves, does not create a new signal. GDACS publishes a new episode when an alert level changes, and each new episode is read.
**Several sources can report one event.** A hurricane can appear in GDACS, NASA EONET and a US weather warning. Each source produces its own signal.
**Only the countries listed have Meteoalarm.** Weather warnings elsewhere in Europe reach you only when GDACS or NASA EONET reports the event.
## Troubleshooting
| What you see | What is happening |
| - | - |
| Sources are added but nothing alerts. | No detector reads them. Enable **Natural Hazard Near a Supplier Site** (Step 2), or add the sources to an existing detector's **Sources**. |
| A hazard hit a region where you have a supplier, but no signal appeared. | The supplier has no site there, or the site has no coordinates yet. Check the vendor's **Locations** card and the [Risk geography map](/user-guides/risk-geography-map). |
| A site with a city was not reached by a nationwide alert. | A site with a city waits for its coordinates instead of matching the whole country. It is matched by distance once it is located. |
| A signal arrived but did not alert. | The detector judged the hazard below your severity threshold. Watches with "possible" certainty are Low at most. |
| A Meteoalarm source collects nothing. | No orange or red warning is active in that country. Yellow warnings are skipped by design. |
## Related
<CardGroup>
<Card title="Working Radar signals" icon="satellite-dish" href="/user-guides/radar-signals">
Reading the signal queue and turning a signal into work.
</Card>
<Card title="Risk geography map" icon="map-location-dot" href="/user-guides/risk-geography-map">
Where your suppliers are, and which sites have been located.
</Card>
<Card title="Source library" icon="rss" href="/products/source-library">
Every source Coverbase draws on, across all tiers.
</Card>
<Card title="Detector library" icon="filter" href="/products/detector-library">
The full catalog of detectors and what each one looks for.
</Card>
</CardGroup>
# Obligations
Source: https://docs.coverbase.com/user-guides/obligations
What your organization owes a vendor: how obligations get extracted from SOC reports and contracts, how to read the list and the record, what each status means, how to assign an owner, ask a business unit to acknowledge one, and where obligations show up elsewhere.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Obligations** page, the obligation record, and the **Configuration → Obligations** settings. For what the module is, see [Obligations Tracker](/products/obligations-tracker). For pulling obligations in and out programmatically, see the [Obligations API](/api-reference/obligations).
</Info>
<Note>
Obligations are an optional module. If you do not see **Obligations** in the left navigation, ask your Coverbase representative to turn it on.
</Note>
An obligation is something your organization has to do because of a vendor relationship. A SOC 2 report says the vendor's controls only work if you enable MFA. A master service agreement says you must notify the vendor within 30 days of a change of control. Neither is a problem with the vendor. Both are work that belongs to someone on your side, and the obligations module is where that work gets a record, an owner and a status.
Coverbase can create these records for you when it analyzes a document, or you can extract them on demand or type one in. Once a record exists you decide whether an internal control already covers it, assign it, set a due date, and mark it satisfied with evidence.
The mistake people make most often is flipping the auto-create switches and expecting obligations to appear for documents that were uploaded last year. Extraction runs when a document is analyzed, so anything analyzed before the switch was on is untouched until you extract from it by hand.
## Obligation, finding, or commitment
Three records look alike and are easy to confuse. Each answers a different question.
| Record | Question it answers | Who does the work |
| - | - | - |
| **Obligation** | What must *we* do because we use this vendor? | Someone in your organization |
| **Finding** | What is wrong on the *vendor's* side? | The vendor, usually through a remediation commitment |
| **Commitment** | Who has promised to do what, by when? | Whoever accepted it: a vendor for a finding, or an internal stakeholder for an obligation |
An obligation can carry a commitment of its own. That is how you ask a business unit to acknowledge it, covered under [Asking a business unit to acknowledge](#asking-a-business-unit-to-acknowledge). Findings and their commitments have their own guide: [Findings and remediation](/user-guides/findings-and-remediation).
## The two types
Every obligation has a **Type**. The extractor picks it, or you set it when extracting by hand.
| Type | What it is | Where it comes from |
| - | - | - |
| **CUEC** | A complementary user entity control: a control the vendor's auditor assumes *you* operate, listed in the vendor's SOC report. | SOC 1 Type 2 and SOC 2 Type 2 reports. Coverbase reads the CUEC list the report already contains. |
| **Shared Responsibility** | A duty the contract puts on your side of the relationship: a notice you must give, a configuration you must maintain, a term you must honor. | Contract documents: order forms, master service agreements, professional service agreements, statements of work, NDAs, amendments, addenda, terms of service, SLAs, software license agreements and generic commercial contracts. Invoices are skipped. |
There are no other types. A technical control you must operate is recorded as whichever of the two it came from, and you link it to an internal control from the record.
## Where obligations live
* **Obligations** in the left navigation: every obligation in your organization, grouped and filtered, with insight cards on the left.
* A vendor's record, **Obligations** tab: the same table scoped to one vendor and grouped by document. Useful when you are reviewing that vendor and want to see what its paperwork asks of you.
* **Configuration → Obligations** (also reachable from the **Actions** menu on the Obligations page, **Configuration**): the three organization-wide switches described next.
<Frame>
<img alt="The Obligations page showing insight cards, a search box, filter and group-by controls, and a table grouped by vendor with statement, type, services, control sets and status columns" />
</Frame>
## Turning on automatic extraction
Only an Admin can change these. Open **Configuration → Obligations**.
<Frame>
<img alt="The Obligations configuration page with three switches: auto-create from vendor CUECs, auto-create from contract shared responsibilities, and require business-unit acknowledgement" />
</Frame>
| Switch | What it does when on |
| - | - |
| **Auto-create obligations from vendor CUECs** | When a SOC 1 Type 2 or SOC 2 Type 2 report finishes analysis and contains CUECs, each CUEC becomes a **CUEC** obligation on that vendor. |
| **Auto-create obligations from contract shared responsibilities** | When a contract document finishes analysis, each shared responsibility Coverbase found becomes a **Shared Responsibility** obligation on that vendor, tied to the services the document is linked to. |
| **Require business-unit acknowledgement** | Changes what happens when an extracted obligation matches an internal control. Instead of being created **Satisfied**, it is created **Pending Acknowledgement** and stays there until a business unit closes a commitment on it. See [Statuses](#statuses). |
Three things to know before you switch them on:
* **Extraction runs at analysis time.** A document analyzed before the switch was on gets nothing. Use **New Obligations → Create or extract from documents** to cover those, or re-run analysis on the document.
* **Every obligation is checked against your internal controls.** If a control in one of your internal control sets already covers the statement, the obligation arrives **Satisfied** with that control linked. If another obligation with the same meaning is already satisfied, the new one arrives **Satisfied** too. Otherwise it arrives **Not Satisfied**. You can see which path an obligation took in its **Compliance Type**.
* **Duplicates are skipped.** A statement that already exists on the same vendor is not created twice.
<Tip>
The control matching only works if you have an internal control set. If you have not built one yet, every extracted obligation will land as **Not Satisfied** and you will be linking controls by hand. Load your internal controls first.
</Tip>
## Reading the list
The top bar, left to right:
* **Search obligations...** matches statement text. Typing expands every group.
* **Filter** opens a menu of **Vendor**, **Vendor Tags**, **Vendor Inherent Risk Level**, **Vendor Residual Risk Level** (only if your organization tracks residual risk), **Status** and **Type**. Applied filters sit under the bar as badges; click a badge to change it, or its cross to remove it.
* **Group by** switches the table between **Vendor / Service** (the default), **Vendor**, **Service** and **Document**. Your choice is remembered.
* **Total obligations** and **Vendor documents** count the whole filtered set, not the page.
* **Expand all** / **Collapse all** on the right, then the **Actions** menu (**Download as Excel**, **Configuration**) and **New Obligations**.
The table is grouped. A group header shows the vendor (a link to the vendor record), or the service, or the document, plus a satisfaction percentage. Hover the percentage to see the count. In **Document** grouping the header also shows the document type badge (hover it for the file name, expiry date and a preview) and, when the source SOC report has expired, a yellow warning icon.
| Column | What it shows |
| - | - |
| **Statement** | The obligation, normalized to a single sentence. The verbatim wording lives on the record under **Original language**. |
| **Type** | **CUEC** or **Shared Responsibility**. |
| **Services** | The vendor services the obligation is scoped to, if any. |
| **Control Sets** | The internal controls linked as satisfying this obligation. |
| **Status** | **Satisfied**, **Not Satisfied** or **Pending Acknowledgement**. Anything not satisfied also carries a small dot: yellow means no commitment or one still waiting for a response, green means a response has arrived. Hover it. |
Click a row to open the record. Click a checkbox, or hold **Shift** and click another, to select rows for bulk actions.
Two details about the shape of the page:
* **Pages are groups, not rows.** The pager counts vendors, services or documents per page, and each group on the page shows every obligation in it, so the header counts are always right.
* **Archived obligations are not listed.** Archiving is permanent from this page. An archived record can still be opened from a link you kept, but it cannot be changed.
The insight cards on the left summarize the whole filtered set: **Activity (30d)** (created versus resolved per day), **Due dates (±30d)** (how many fall due each day, hover a bar for the vendors), **Satisfaction rate**, and leaderboards of **Assignees** and **Top vendors** that you can flip between **Most** and **Unsatisfied**. The chevron at the far left of the bar hides the cards.
<Note>
If a banner reads **Showing only the items assigned to you**, your role sees obligations at assigned scope. You can act on your own; you cannot see the rest. See [Permissions](#permissions).
</Note>
## Statuses
An obligation's status is written when it is created and changed by people afterwards. Nothing recomputes it in the background except the two events noted below.
| Status | Meaning | How it gets there |
| - | - | - |
| **Satisfied** | Your organization meets this obligation. | Extraction matched an internal control or a similar satisfied obligation; someone linked a satisfying control; someone clicked **Mark as satisfied**; or a business unit closed its commitment on a pending obligation. |
| **Not Satisfied** | Nobody has shown that you meet it. This is the default. | Extraction found no match; someone clicked **Mark as not satisfied**; every satisfying control was removed; or the control that satisfied it was archived. |
| **Pending Acknowledgement** | A control matched, but your organization requires a business unit to confirm it operates before it counts. | Only created by extraction when **Require business-unit acknowledgement** is on. Becomes **Satisfied** when a commitment on it reaches **Closed**. |
Alongside the status, a satisfied obligation carries a **Compliance Type** that records why it is satisfied:
| Compliance Type | Meaning |
| - | - |
| **Internal Control** | One or more of your internal controls is linked under **Satisfying Controls**. Removing the last one flips the obligation back to **Not Satisfied**. |
| **Similar Obligation** | Extraction found an obligation with the same meaning that was already satisfied. |
| **Manual** | Someone used **Mark as satisfied** without linking a control. |
<Warning>
Archiving an internal control unlinks it from every obligation it satisfied. An obligation left with no satisfying controls goes back to **Not Satisfied**, and the change is written to its activity log. If you retire a control, check the obligations that leaned on it.
</Warning>
## Creating obligations
Besides the automatic switches, there are three ways in. All of them need the obligation create permission (an Admin, or a custom role with it).
<Frame>
<img alt="The Extract obligations from documents modal, step 2, with document selection, an upload area, obligation type set to Auto-detect, services, assignee and due date fields" />
</Frame>
<AccordionGroup>
<Accordion title="Extract from documents" icon="file-magnifying-glass">
<Steps>
<Step title="New Obligations → Create or extract from documents">
Step 1 asks for a vendor. Pick one to move to step 2.
</Step>
<Step title="Choose the documents">
Under **Documents**, select any of the vendor's existing documents, drop new files into the upload area, or both. New files are added to the vendor (and to any services you pick below) before extraction starts.
</Step>
<Step title="Set the type, services, owner and date">
**Obligation type** defaults to **Auto-detect**, which lets the extractor classify each statement. Choose **CUEC** or **Shared Responsibility** to force every result to one type. **Services** scopes the results to the vendor's services. **Assignee** and **Due Date** are applied to every obligation the run creates, so leave them blank if the owners will differ.
</Step>
<Step title="Extract obligations from documents">
The job runs in the background. You get an in-app notification and an email when it finishes, with the count created and, when a document already had obligations, the count of statements that were already on file and skipped. A statement is skipped when the same obligation is already recorded against that document, even if it is worded differently. The same control matching as automatic extraction runs on each result.
Before you start, the modal tells you how many obligations the selected documents already carry, so a low created count on a re-run reads as expected rather than as a failure. On a SOC 1 or SOC 2 report the extractor reads only the complementary user entity controls section; on a contract it reads the whole document.
</Step>
</Steps>
</Accordion>
<Accordion title="Extract from one document on the vendor record" icon="file-lines">
On a vendor's **Documents** tab, open a document's actions menu and choose **Extract obligations**. It runs the same job for that one document, with **Auto-detect** type, the document's own service links, no assignee and no due date.
</Accordion>
<Accordion title="Create manually" icon="plus">
**New Obligations → Create manually**, pick the vendor, then fill in **Vendor Document** (required, the obligation has to cite a source), **Statement** (required), **Status**, **Obligation Type** (**CUEC** only for hand-typed records), **Assignee**, **Due Date** and **Satisfying Controls**. Picking at least one control sets the status to **Satisfied** with compliance type **Internal Control**, whatever you chose under **Status**. Click **Create Obligation**.
</Accordion>
</AccordionGroup>
## The obligation record
Clicking a row opens the record in a side panel. Its URL (`/obligations/req/<id>`) is shareable; the link icon next to the **Obligation** badge copies it. The expand button widens the panel.
<Frame>
<img alt="The obligation side panel showing the document name and type badge, a yellow not-satisfied banner with Mark as satisfied, a details table with statement, original language, type, compliance status and source, followed by assignee and due date fields and a satisfying controls picker" />
</Frame>
From the top:
1. **Header.** The source document's name and type badge, or **Custom Obligation** for a record with no document. An expired SOC report shows an expiry badge. Underneath, **Created** and **Updated**, and, when the source report has expired, the hint **May be stale - source document expired** with an **Archive** link.
2. **Status banner.** Green for **Obligation satisfied**, yellow for **Obligation not satisfied** (a pending obligation shows the yellow banner too). The banner carries **Mark as satisfied** or **Mark as not satisfied**, and a menu with **Archive obligation**. Both status buttons open a small dialog with an optional **Reason**; the reason is saved as a note on the obligation. Marking not satisfied also clears the linked controls and compliance type.
3. **Obligation table.** **Statement** (click **Edit** to reword it), **Original language** (the verbatim text, shown only when it differs from the statement), **Type**, **Compliance Status**, **Compliance Type**, **Matched control set** (the internal control set the satisfying controls belong to), **Created By**, and **Source**, which expands to the document itself.
4. **Commitment.** Appears only when a commitment has been requested. See [Asking a business unit to acknowledge](#asking-a-business-unit-to-acknowledge).
5. **Assignee** and **Due Date.** Saved as soon as you change them. The calendar does not offer past dates.
6. **Satisfying Controls.** A picker over your internal control sets, with a **View internal controls** link. Add a control and the obligation becomes **Satisfied** / **Internal Control**; remove the last one and it becomes **Not Satisfied**.
7. **Services.** The vendor's services this obligation applies to. Only that vendor's services are offered.
8. **Evidence Uploads.** Drop files (up to 100 MiB each) that prove the obligation is met. Each file can carry a note, and you can preview, open or remove it.
9. **Activity** and **Notes.** Every field change, including system changes, and a place to discuss the obligation. A note also emails the vendor's relationship owners if the obligation has an active commitment portal, so they can respond there.
An archived obligation opens with an **Obligation Archived** notice and every control disabled.
## Reviewing extracted obligations
Extraction is tuned to surface too much rather than too little, so a review pass is part of the job. For each new obligation:
<Steps>
<Step title="Read the statement against the original language">
Open the record and compare **Statement** with **Original language**. If the normalized sentence lost the meaning, click **Edit** and fix it. If it is not an obligation at all (a description of the vendor's own control, say), archive it.
</Step>
<Step title="Check what matched">
If the record arrived **Satisfied** with compliance type **Internal Control**, look at **Matched control set** and **Satisfying Controls** and confirm the control really covers this obligation. Remove it if not; the obligation drops back to **Not Satisfied**.
</Step>
<Step title="Scope it to a service">
A vendor with several services under different contracts needs the obligation on the right one. Set **Services**.
</Step>
<Step title="Give it an owner and a date">
Set **Assignee** to whoever can satisfy it, not to the contract owner by default. Set a **Due Date** that matches the contract's own deadline. The **Contract obligation ownership** workflow template raises a task for exactly this step; see [Workflow templates](/user-guides/workflow-templates#contract-obligation-ownership).
</Step>
<Step title="Decide how it is satisfied">
Link a control, mark it satisfied by hand with a reason and evidence, or request a commitment from the business unit that runs it.
</Step>
</Steps>
## Ownership and reassignment
**Assignee** takes a person or a user group. When you assign a group, Coverbase routes it according to that group's rule and notifies the member who was picked. Assigning a single person changes the record and its activity log; it does not send an email on its own. Group routing, round-robin and out-of-office rules are covered in [Assignment, delegation and out of office](/user-guides/assignment-and-delegation).
To reassign several at once, select the rows and use **Change Assignee** in the floating bar. Picking **Unassigned** clears the owner.
The assignee matters for permissions: a role that can edit obligations at assigned scope can only change the obligations assigned to them or to a group they belong to.
## Asking a business unit to acknowledge
An obligation is often satisfied by a team that never opens Coverbase. **Request Commitment** sends them a portal listing the obligations, and records what they say.
<Frame>
<img alt="The Request commitment modal showing a due date field, a description with AI autofill, and a list of the selected obligation statements" />
</Frame>
<Steps>
<Step title="Pick the obligations">
Switch **Group by** to **Document** and click **Request Commitment** on a document's group header. The unsatisfied obligations in that group are pre-ticked; adjust the ticks, then **Continue**. You can also tick rows first and use **Request Commitment** in the floating bar, which appears only when every selected row comes from the same document.
</Step>
<Step title="Set a due date and description">
**Due date** is pre-filled with the earliest due date among the selected obligations, or 60 days out if none has one. The description is drafted for you (AI autofill runs once; the sparkle re-runs it) and explains what you are asking. Click **Continue**.
</Step>
<Step title="Send the invitation">
**To** is pre-filled with the vendor's relationship owners, the internal people who own the relationship. The obligations' assignees are added on CC. Edit the recipients and the message, then send.
</Step>
</Steps>
What happens next:
* One commitment is created per obligation, and all of them are attached to the vendor's persistent portal, which is reopened if it had been closed. Each record's status badge gains a **Commitment Requested** tag.
* The recipient opens an **Obligations Portal**. For each obligation they can **Commit** (acknowledge it and take it on), choose **Already satisfied** (describe the existing control and attach evidence), **Add a comment or propose changes** (different terms or a different date), or **Decline** (a reason is required). When the recipient answers in the [centralized supplier portal](/user-guides/centralized-supplier-portal), each commitment there also shows the obligation's type (**Complementary control** or **Shared responsibility**) and the document it was read from.
* Back on the record, the **Commitment** section shows the status (**Pending response**, **Response received**, **Mitigation underway**, **Declined**, **Closed**), the response type, any proposed completion date and notes, a **View submission** link, and **Reopen to pending** for anything that has moved past pending.
* When a commitment reaches **Closed**, an obligation that was **Pending Acknowledgement** becomes **Satisfied**. An obligation in any other status keeps its status; closing the loop is still yours to record.
The commitment statuses, who moves them and how, are the same as for findings: [Working a commitment](/user-guides/findings-and-remediation#working-a-commitment).
## Acting on several at once
Select rows (or a whole group with the checkbox in its header) and the floating bar offers:
<Frame>
<img alt="The obligations table with several rows selected and a floating bar offering Change Assignee, Change Status, Request Commitment, Set Due Date, Set Controls and Archive" />
</Frame>
| Action | What it does |
| - | - |
| **Change Assignee** | Sets one owner on every selected obligation, or clears it. |
| **Change Status** | **Satisfied** or **Not Satisfied**, without a reason dialog. |
| **Request Commitment** | Only offered when every selected row comes from the same document. Opens the flow above. |
| **Set Due Date** | One date for all, or **Clear due date**. |
| **Set Controls** | Links the chosen internal controls to every selected obligation. This **replaces** each one's existing links. **Clear all** removes them, which sets the obligations back to **Not Satisfied**. |
| **Archive** | Asks for confirmation. Archived obligations leave the list and cannot be restored from the page. |
## Exporting
**Actions → Download as Excel** opens **Build Obligations Report**. Give it an **Export file name** and choose whether to **Apply current filters to the export**. The sheet has one row per obligation: statement, type, status, compliance type, vendor, document, assignee, due date, created by, created and updated dates, and the satisfying controls.
## Emails and notifications
| Email or notification | Who gets it | When |
| - | - | - |
| **Obligation extraction status** (in-app and email) | The person who started the extraction | An extraction from documents finishes. Subject: "Obligation extraction for `<vendor>` completed", or "failed" with a request to try again. The body gives the count created and, on a re-run, how many statements were already on file and skipped. |
| **User group assignments** | The group member Coverbase picked | An obligation is assigned to a user group. |
| Commitment invitation | The vendor's relationship owners (**To**) and the obligations' assignees (**CC**), as edited before sending | You send a **Request Commitment** invitation. |
| **Obligation note** | The vendor's relationship owners (or the vendor contacts if there are none) | You add a note on an obligation that has an active commitment portal. |
Delivery settings for the first two are per person under notification settings; see [Email and notifications](/user-guides/email-notifications#vendors-and-portals).
## Where obligations show up elsewhere
* **Vendor record.** The **Obligations** tab, and **Include obligations** in the vendor report export.
* **Archiving cascades.** Archiving a vendor archives its obligations. Archiving a document archives the obligations extracted from it.
* **Risk register.** With the Risk module, an obligation that is **Not Satisfied** past its due date, or **Pending Acknowledgement** for longer than the configured window (14 days by default), becomes a risk signal on the vendor. The signal clears when the obligation is satisfied or archived.
* **Workflows.** The **Contract obligation ownership** template fires when an obligation is raised against a vendor's document and creates a task to assign it. See [Workflow templates](/user-guides/workflow-templates#contract-obligation-ownership).
* **Webhooks.** `Obligation.Created`, `Obligation.Updated` (with a field diff) and `Obligation.Deleted`. See [Webhooks](/api-reference/webhooks).
* **API and MCP.** `GET`, `POST` and `PATCH` on `/v1/obligations` for GRC round-trips ([Obligations API](/api-reference/obligations)), and the `obligations` query plus `obligation` create and update in the [MCP server](/mcp/overview).
## Permissions
| Role | Obligations | Configuration |
| - | - | - |
| **Admin** | Read, create, extract, update, bulk actions, archive | Yes |
| **Member** (default) | Read only. Can act on obligations assigned to them only if their role grants update at assigned scope | No |
| Custom role | Whatever `obligation` actions and scope it carries. **Request Commitment** additionally needs commitment create | Needs organization settings update |
| **Service Account** | Read, create and update through the public API | No |
How resources, actions and scopes combine is in [Permissions and roles](/user-guides/permissions-and-roles).
## Troubleshooting
| What you see | What is happening |
| - | - |
| "I turned on auto-create and nothing appeared." | Extraction runs when a document is analyzed. Documents analyzed before the switch was on are untouched. Use **New Obligations → Create or extract from documents** for them, or re-run the document's analysis. |
| "A contract was analyzed but produced no obligations." | Only contract document types are read for shared responsibilities, and only when Coverbase found responsibilities on your side. Invoices never produce obligations. Try **Extract obligations** on the document to run the extractor over the full text. |
| "Everything arrived Not Satisfied." | You have no internal control set, or none of its controls describe what the obligations ask. Matching uses the control's own guidance text. Build or tighten the set, then link controls by hand or re-extract. |
| "The obligation says Satisfied but I never did anything." | Look at **Compliance Type**. **Internal Control** means a control matched: check it under **Matched control set**. **Similar Obligation** means an obligation with the same meaning was already satisfied. |
| "An obligation flipped back to Not Satisfied on its own." | The control that satisfied it was archived. The activity log records it. Link another control or mark it satisfied with a reason. |
| "Request Commitment is missing from the floating bar." | The selected rows come from more than one document. Select within one document, or use the button on the group header in **Document** grouping. |
| "The invitation has nobody in To." | The vendor has no relationship owners. Add them on the vendor record, or type the addresses in. |
| "The business unit committed but the obligation is still Pending Acknowledgement." | Only a commitment that reaches **Closed** flips it. Committing moves it to **Mitigation underway**; someone still has to close it. |
| "I cannot edit anything on the record." | Either the obligation is archived (see the notice at the top), or your role reads obligations without updating them. Ask an Admin. |
| "I archived an obligation by mistake." | Archiving cannot be undone from the page. Recreate it with **Create manually**, or ask for it to be restored through the API (`PATCH` with `is_archived: false`). |
| "A yellow warning sits on the document group." | The source SOC report has expired, so its CUECs may be stale. Open each record; the header offers **Archive** if the newer report replaces them. |
| "I re-ran extraction on a document and the count barely moved." | That is the expected result. A re-run adds only statements not already on file for that document; the completion email says how many were skipped. Run it when you believe the first pass missed something, not to refresh what is there. |
| "A document has the same obligation twice." | The two records were created before duplicate detection compared meaning as well as wording, or the extractor could not tell them apart. Select both in the list, keep the one that carries status and evidence, and archive the other from the floating bar. |
| "A new SOC report arrived and last year's obligations are still listed." | Each report produces its own obligations, and a newer report does not retire an older one yet. Obligations from the new report that match a satisfied one from the old report arrive **Satisfied** with compliance type **Similar Obligation**. Archive the old report's obligations from the document group once you have checked that carried over, or leave them for history. |
## Related
<CardGroup>
<Card title="Findings and remediation" icon="flag" href="/user-guides/findings-and-remediation">
The vendor-side counterpart: findings, remediation commitments and the portal recipients see.
</Card>
<Card title="Assignment, delegation and out of office" icon="users" href="/user-guides/assignment-and-delegation">
How a user group routes an obligation to a person, and what happens when they are away.
</Card>
<Card title="Workflow templates" icon="diagram-project" href="/user-guides/workflow-templates">
Contract obligation ownership and the other automations that react when records are raised.
</Card>
<Card title="Obligations API" icon="code" href="/api-reference/obligations">
List, create and status-sync obligations from your GRC platform.
</Card>
</CardGroup>
# Offboarding and continuity
Source: https://docs.coverbase.com/user-guides/offboarding-and-continuity
Set lifecycle routing, complete the executed contract handoff, write a continuity plan for a critical engagement, file and approve an offboarding request, work the exit plan with evidence and the vendor's destruction certificate, and read what stops automatically.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers an engagement's **Contract** and **Exit** tabs. It sits beside [The engagement record](/user-guides/engagement-record) and [Monitoring plans](/user-guides/monitoring-plans), whose owner attestation is the usual start of an offboarding. For what the module is, see [Offboarding and continuity](/products/offboarding-and-continuity).
</Info>
This guide covers the engagement's life after due diligence: filing the executed contract, planning for the day the vendor is gone, and ending the relationship with evidence that each exit step was done.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
The mistake people make most often is approving an exit plan step on a note that says "done". A step closes only when its evidence is submitted and its approver approves it, and the data step needs the vendor's signed destruction certificate, not a note.
## Step 1: Set lifecycle routing
Open **Configuration**, choose **Communications**, and under **Lifecycle Routing and Reminders** choose the **TPRM Office** and **Supply Chain** user groups. Offboarding approvals and the executed contract task go to these groups, each following the group's own assignment rule (round robin gives one person the task, assign to all gives everyone one).
* With no TPRM Office group, offboarding approval goes to the vendor's first risk analyst, then the requester.
* Supply Chain approval is required only once its group is named. Left unset, the TPRM Office approves offboarding alone.
* The approvals a request needs are fixed when it is filed. Changing routing later does not change requests already filed.
## Complete the contract handoff
The **Contract** tab lists the engagement's **Contracts** and its **Execution Handoff**.
<Frame>
<img alt="Contract tab for Consumer analytics platform with an Execution Handoff card labeled Waiting for execution, an Upload executed contract task assigned to Daniel Sato, and a Signed on paper section asking to link the contract first" />
</Frame>
A handoff opens by itself when an assessment completes for an engagement that has not started, or when the Transaction Owner chooses **Proceed to contracting** on the Risk Summary. To start one by hand, when due diligence was decided elsewhere, click **Start handoff**. Supply Chain (or the TPRM Office) gets an **Upload executed contract** task.
* **Signed through e-signature:** nothing to do. The handoff completes when the envelope is executed.
* **Signed on paper:** under **Signed on paper**, choose the **Contract**, drop the executed copy, and click **File executed contract**. If the contract is not listed, link it from **About Engagement** on the **Overview** tab first.
On completion the engagement moves to its active status, and the Transaction Owner and the TPRM Office are notified.
## Write a continuity plan
An engagement whose inherent risk is the highest level of its scale is critical, whatever you call that level. When it reaches that level, a draft **Third-Party Continuity Plan** opens on the **Exit** tab and its Transaction Owner gets a task. Any other engagement can have a plan too.
Fill in the **Owner**, **Backup Suppliers** (with readiness notes), the **Exit Strategy**, the **Recovery Time Objective (Hours)**, **Resiliency Notes** and **Transition Steps**, one per line. **Save draft** keeps your work. **Submit plan** needs an exit strategy and a recovery time objective. **Reopen plan** makes a submitted plan editable again.
If the engagement is offboarded, each transition step becomes an exit plan step.
## Step 2: Request offboarding
On the **Exit** tab, under **Request Offboarding**, choose a **Reason** (**Consolidation**, **Contract ending**, **No longer needed**, **Performance**, **Risk**, **Cost** or **Other**), write the **Business Justification**, optionally pick a **Requested Date**, and click **Request offboarding**.
An engagement has at most one open request. One also opens automatically when:
* an owner answers **Start offboarding** on a monitoring plan attestation, or
* someone marks the engagement not in use (a canceled status, or a status labeled Inactive or Not in use), or marks every service it uses not in use.
## Step 3: Approve it
The **Offboarding Request** card shows **Waiting for TPRM Office** and, if required, **Waiting for Supply Chain**. A member of each group, or an admin, clicks **Approve**. The last approval starts the request: Coverbase generates the exit plan and runs the start of the cascade.
From the moment the request is filed, the engagement's tracker shows **Exit** as the current stage, reading **Exit under way**. See [The engagement record](/user-guides/engagement-record#step-2-open-the-engagement).
**Cancel offboarding**, with a **Cancel Reason**, closes every open step and task, and the tracker goes back to **Active**. Anything already stopped stays stopped.
## Step 4: Work the exit plan
<Frame>
<img alt="Exit plan with three open steps grouped by source, each with its evidence gate, owner, approver and a Request certificate or Submit evidence button, beside the Offboarding Request and What Stops Automatically cards" />
</Frame>
**Exit Plan** lists the steps built from what the engagement had, grouped by source: **Data it held**, **Access it had**, **Integrations**, **Contract** and **Continuity**. Each step has an **Owner** (the Transaction Owner for data, contract and continuity, the requester for access and integrations) and an **Approver** (the TPRM approver).
<Steps>
<Step title="Submit evidence">
The owner clicks **Submit evidence**. A document step needs a file, a sign-off step a note. The step moves to **Awaiting approval**.
</Step>
<Step title="Approve or return">
The approver clicks **Approve**, or **Return** with what needs to change. A returned step goes back to its owner with the note.
</Step>
</Steps>
The plan lists a page of steps at a time. Filter by **Source**, or choose **My steps** to see only what waits on you.
To work several steps at once, select them:
* **Submit evidence for N steps** sends one file, one note or both to every selected step. Each step still has to pass its own gate, so a document step without a file or a sign-off step without a note is listed with what it needs, and the rest go through. A certificate step goes through only once the vendor has signed.
* **Approve N steps** approves the selected steps that wait on you. Each closes with the evidence it has; a step you cannot approve is skipped and listed with the reason.
**Remind owners** emails every owner of a step waiting on evidence and every approver of a step waiting on a decision, except you. It can be used once a day per request.
**Rebuild from current data** refreshes the plan from the record. It adds new steps and updates text without duplicating a step or losing what someone already did on it.
## Get the vendor's destruction certificate
The data step closes on a certificate the vendor signs. Click **Request certificate** on the step. The vendor gets an informational request in the supplier portal with a data destruction certificate to sign; **Copy portal link** gives you the link to send. When they sign, the step shows **Signed by**, with their title and the date, and **Vendor Attestation** shows a digest of the certificate.
Submitting the step records that digest. If the signed certificate changes afterwards, approval is refused, so the approver always approves the certificate they saw.
If the engagement held no data on record, the data step is instead an owner sign-off that no data is held.
## What stops automatically
**What Stops Automatically** lists what the offboarding will change, and keeps a line for anything another live engagement still needs (**Kept**).
| When | What | Rule |
| - | - | - |
| On approval | In-flight due diligence | Canceled when scoped to a service no other live engagement uses, or all of the vendor's when no other engagement remains |
| On approval | A pending executed contract task | Canceled |
| When the plan closes | The engagement | Set to your inactive engagement status |
| When the plan closes | Its services | Inactive, unless another live engagement uses them |
| When the plan closes | The vendor | Inactive only when no other live engagement remains, which also stops its reassessments |
| When the plan closes | Radar monitoring | Stopped only when the vendor goes inactive |
| When the plan closes | The open monitoring record | Closed only when the vendor goes inactive |
Approving the last open step completes the request, and the requester, the Transaction Owner and the TPRM approver are notified. The card then reads **Offboarded**, and the tracker's **Exit** stage reads **Exited** with the date. An exited engagement leaves the figures in [Program Insights](/user-guides/program-insights).
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **Exit** or **Contract** tab | The third-party lifecycle features are not turned on for your organization. | Ask your Coverbase representative. |
| **Link the contract to this engagement first.** | No contract is linked to the engagement. | Link it from **About Engagement** on the engagement's **Overview** tab. |
| The paper-signed contract still reads as not executed in its signature workflow | Only e-signature sets that state. | Expected. The handoff, the engagement status and the notices are the same. |
| **Request offboarding** is refused | The engagement already has an open request. | Work or cancel the open request. |
| Supply Chain approval is not asked for | No Supply Chain group was named when the request was filed. | Expected for that request. Name the group for future requests. |
| **Submit plan** is refused | The exit strategy or recovery time objective is empty. | Fill both in. |
| Approving the data step is refused | The vendor's signed certificate changed after the step was submitted. | **Return** the step so its owner submits it again with the current certificate. |
| A service stayed active after offboarding | Another live engagement uses it. | Expected. It shows as **Kept**. |
## Related
<CardGroup>
<Card title="Monitoring plans" icon="calendar-check" href="/user-guides/monitoring-plans">
Owner attestation and Start offboarding.
</Card>
<Card title="The engagement record" icon="route" href="/user-guides/engagement-record">
The Risk Summary decision that opens a handoff.
</Card>
<Card title="Contract intake and approval" icon="clipboard-check" href="/user-guides/contract-intake-and-approval">
Approval chains and sending for signature.
</Card>
<Card title="Assignment, delegation and out of office" icon="user-clock" href="/user-guides/assignment-and-delegation">
How a group assigns its tasks.
</Card>
</CardGroup>
# User guides
Source: https://docs.coverbase.com/user-guides/overview
Every Coverbase how-to guide in one place, grouped the way the product is: vendors, assessments, findings and obligations, vendor intelligence, monitoring and risk, contracts and e-signature, documents, workflows, reporting, sourcing and internal controls.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
These are the screen-by-screen guides for using Coverbase. Each one is written for someone with the product open in another tab who wants to finish a specific job today. None of them assumes prior Coverbase experience, and each can be read on its own.
The guides are grouped the way the left navigation in the product is grouped, so the section a screen sits in is the section its guide sits in. This page is the directory. Use the sidebar to browse, or the [complete directory](#the-complete-directory) and the [lookup table](#looking-something-up) below to jump straight to an answer.
## Start here
Pick the guide that matches your role. Most people only ever need one of these three.
<CardGroup>
<Card title="I am setting up Coverbase" icon="sliders" href="/user-guides/admin-setup">
**Admin and setup guide.** Import your vendors, build tags and the intake questionnaire, tune scales and control sets, then set templates, monitoring and integrations. This is where the AI gets its instructions.
</Card>
<Card title="I run vendor risk day to day" icon="user-check" href="/user-guides/analyst-reviewer">
**Analyst and reviewer guide.** Triage requests, launch assessments, review and correct what the AI found, follow up with vendors, and close the loop with findings and reports.
</Card>
<Card title="I need a tool approved" icon="cart-shopping" href="/user-guides/requesting-a-vendor">
**Requesting a new vendor.** The short one, for the business requester. What you will be asked, how to file it, and why submitting a request is not approval.
</Card>
</CardGroup>
An admin configures the environment once. After that, analysts run assessments against that configuration every day, and every correction a reviewer makes carries forward into future assessments.
## Setting up your workspace
Do this once, in order. The setup guide is the spine. The guides beside it cover the settings people most often discover too late.
<CardGroup>
<Card title="Admin and setup guide" icon="sliders" href="/user-guides/admin-setup">
Eleven steps from an empty environment to a running program: vendors, tags, the intake questionnaire, scales, control sets, assessment plans, templates, Radar, obligations and integrations.
</Card>
<Card title="Configuring your data model" icon="table-columns" href="/user-guides/data-model-configuration">
What an admin changes without a professional-services engagement: custom fields, statuses, approval options, scales, risk domains, terminology, relationships and automations.
</Card>
<Card title="Permissions and roles" icon="lock-keyhole" href="/user-guides/permissions-and-roles">
The six default roles, how a permission is built from a resource, an action and a scope, and how to build and assign a custom role.
</Card>
<Card title="Assignment, delegation and out of office" icon="user-clock" href="/user-guides/assignment-and-delegation">
How a gate reaches a person: user groups, round-robin and assign-to-all routing, out-of-office windows that skip a member automatically, and the assignment log.
</Card>
<Card title="Reviews, approvals and gates" icon="gavel" href="/user-guides/reviews-and-approvals">
Configurable gate outcomes, parallel domain-scoped SME reviews, multi-approver and threshold logic, and return-for-rework loops with reasons and round counts.
</Card>
<Card title="Email and notifications" icon="envelope" href="/user-guides/email-notifications">
Every email Coverbase sends to your team and your vendors, how each person controls delivery and digests, and how your logo and brand color reach emails and portals.
</Card>
<Card title="White-labeling your vendor-facing domain" icon="globe" href="/user-guides/white-labeling">
Sending vendor email and hosting the portal on your own subdomain, and choosing between Coverbase-managed and organization-managed DNS.
</Card>
<Card title="Webhooks" icon="tower-broadcast" href="/user-guides/webhooks">
Register the HTTPS endpoints Coverbase sends events to: choose each endpoint's events, set its signing secret, send a test event, and read its delivery history.
</Card>
</CardGroup>
Jump straight to a step: [setup checklist](/user-guides/admin-setup#setup-checklist) · [import your vendors](/user-guides/admin-setup#step-2-import-your-vendor-portfolio) · [tag structure](/user-guides/admin-setup#step-3-create-your-tag-structure) · [build and weight the IRQ](/user-guides/admin-setup#step-4-build-and-weight-your-irq) · [control sets](/user-guides/admin-setup#step-6-upload-and-tune-control-sets) · [assessment plans and cadence](/user-guides/admin-setup#step-7-assessment-plans-and-reassessment-cadence) · [configure Radar](/user-guides/admin-setup#step-9-configure-radar-continuous-monitoring) · [integrations and Export API](/user-guides/admin-setup#step-11-integrations-and-export-api-optional) · [admin quick reference](/user-guides/admin-setup#admin-quick-reference)
Access and notifications: [the six default roles](/user-guides/permissions-and-roles#the-six-default-roles) · [building a custom role](/user-guides/permissions-and-roles#building-a-custom-role) · [user groups](/user-guides/assignment-and-delegation#user-groups) · [out of office](/user-guides/assignment-and-delegation#out-of-office) · [gate outcomes](/user-guides/reviews-and-approvals#gate-outcomes-are-yours-to-define) · [return for rework](/user-guides/reviews-and-approvals#return-for-rework) · [choosing an email layout](/user-guides/email-notifications#choosing-a-layout) · [applying your branding](/user-guides/email-notifications#applying-your-own-branding) · [who receives what](/user-guides/email-notifications#who-receives-what) · [the notification catalog](/user-guides/email-notifications#the-notification-catalog) · [two ways to set up your domain](/user-guides/white-labeling#two-ways-to-set-it-up)
## Vendors
The vendor record is where everything else attaches: services, engagements, documents, assessments, contracts, findings, obligations and the supplier's bank and tax details.
<CardGroup>
<Card title="The vendor record" icon="building" href="/user-guides/vendor-record">
The vendor list and one vendor's page: tabs and sidebar cards, services and engagements, subprocessors and nth parties, owners and directory contacts, custom fields, tags, and archiving.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How bank details, addresses, tax registrations and diversity records are collected through a questionnaire, checked against the rules for the supplier's country, reviewed before they take effect, and handed to your finance system.
</Card>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
All 109 countries Coverbase validates, with the exact fields, formats, check digits and registers each one uses. Useful before you send a request, and when you are reading a warning on a submitted record.
</Card>
<Card title="Requesting a new vendor" icon="cart-shopping" href="/user-guides/requesting-a-vendor">
The requester's side of intake: filing in the portal or in chat, what you will be asked, how to get through it faster, and what happens after you submit.
</Card>
<Card title="Centralized supplier portal" icon="door-open" href="/user-guides/centralized-supplier-portal">
One page where a supplier signs in and sees every request you have open with them, keeps their own profile current, and answers your findings. How to turn it on and what each setting decides.
</Card>
<Card title="The supplier portal, for suppliers" icon="user-group" href="/user-guides/supplier-portal-for-suppliers">
The page to send a supplier: signing in, everything open with you in one place, keeping their details current, and bringing colleagues in.
</Card>
</CardGroup>
Jump straight to an answer: [two ways to file a request](/user-guides/requesting-a-vendor#two-ways-to-file-one) · [getting through it faster](/user-guides/requesting-a-vendor#getting-through-it-faster) · [turning on the centralized portal](/user-guides/centralized-supplier-portal#turning-it-on) · [what a supplier may change without being asked](/user-guides/centralized-supplier-portal#what-a-supplier-may-change-without-being-asked) · [how a supplier gets in](/user-guides/supplier-portal-for-suppliers#getting-in) · [the four supplier question types](/user-guides/supplier-information#asking-a-supplier-the-four-question-types) · [the review that stops fraud](/user-guides/supplier-information#review-the-part-that-stops-fraud) · [who can see and do what](/user-guides/supplier-information#who-can-see-and-do-what) · [getting it into your finance system](/user-guides/supplier-information#getting-it-into-your-finance-system)
<Accordion title="Every country page, by name" icon="globe">
Each page lists the exact fields, formats, check digits and registers for that country. The [country overview](/user-guides/supplier-countries/overview) has the full table of all 109.
[Australia](/user-guides/supplier-countries/au) ·
[Brazil](/user-guides/supplier-countries/br) ·
[Bulgaria](/user-guides/supplier-countries/bg) ·
[Canada](/user-guides/supplier-countries/ca) ·
[China](/user-guides/supplier-countries/cn) ·
[Colombia](/user-guides/supplier-countries/co) ·
[Côte d'Ivoire](/user-guides/supplier-countries/ci) ·
[Finland](/user-guides/supplier-countries/fi) ·
[France](/user-guides/supplier-countries/fr) ·
[Germany](/user-guides/supplier-countries/de) ·
[Ghana](/user-guides/supplier-countries/gh) ·
[Hong Kong SAR](/user-guides/supplier-countries/hk) ·
[India](/user-guides/supplier-countries/in) ·
[Indonesia](/user-guides/supplier-countries/id) ·
[Ireland](/user-guides/supplier-countries/ie) ·
[Italy](/user-guides/supplier-countries/it) ·
[Japan](/user-guides/supplier-countries/jp) ·
[Malaysia](/user-guides/supplier-countries/my) ·
[Mauritius](/user-guides/supplier-countries/mu) ·
[Mexico](/user-guides/supplier-countries/mx) ·
[Netherlands](/user-guides/supplier-countries/nl) ·
[Nigeria](/user-guides/supplier-countries/ng) ·
[Oman](/user-guides/supplier-countries/om) ·
[Peru](/user-guides/supplier-countries/pe) ·
[Philippines](/user-guides/supplier-countries/ph) ·
[Poland](/user-guides/supplier-countries/pl) ·
[Portugal](/user-guides/supplier-countries/pt) ·
[Saudi Arabia](/user-guides/supplier-countries/sa) ·
[Singapore](/user-guides/supplier-countries/sg) ·
[South Africa](/user-guides/supplier-countries/za) ·
[South Korea](/user-guides/supplier-countries/kr) ·
[Spain](/user-guides/supplier-countries/es) ·
[Sweden](/user-guides/supplier-countries/se) ·
[Switzerland](/user-guides/supplier-countries/ch) ·
[Thailand](/user-guides/supplier-countries/th) ·
[Türkiye](/user-guides/supplier-countries/tr) ·
[United Arab Emirates](/user-guides/supplier-countries/ae) ·
[United Kingdom](/user-guides/supplier-countries/gb) ·
[United States](/user-guides/supplier-countries/us)
</Accordion>
## Third-party lifecycle
From the first triage of a request to the exit, for organizations with the third-party lifecycle features turned on. These guides use the roles the module is built around: the **Transaction Owner** who asks for the vendor, the **TPRM Office** that runs the program, and the **Risk Groups** that review each risk domain.
<CardGroup>
<Card title="Intake Agent" icon="comments" href="/user-guides/intake-agent">
Let requesters ask for a new vendor in Slack, Teams, email or their AI assistant, and follow the conversations.
</Card>
<Card title="Front Door triage" icon="door-open" href="/user-guides/front-door-triage">
Decide whether a request is new, whether earlier due diligence can be reused, whether it needs an IRQ, and whether the vendor is on the Do Not Use list, with two sign-offs.
</Card>
<Card title="Risk methodology" icon="scale-balanced" href="/user-guides/risk-methodology">
Domain weights, how ratings roll up, the reviewer matrix, escalation rules, questionnaire versions, and overrides with a rationale and expiry.
</Card>
<Card title="Due diligence methods and the portal" icon="magnifying-glass-chart" href="/user-guides/due-diligence-methods-and-portal">
Review sessions, question delegation, carried-forward answers, reviewer edits the supplier approves, and service-level sends.
</Card>
<Card title="Claim check" icon="scale-unbalanced" href="/user-guides/claim-check">
Test each questionnaire answer against the evidence on file, with cited passages, then raise findings or ask the vendor.
</Card>
<Card title="The issue acceptance chain" icon="list-ol" href="/user-guides/issue-acceptance-chain">
Route accepting a finding's risk through the owner, a Risk Group, the TPRM Office and an extended approver.
</Card>
<Card title="The engagement record" icon="route" href="/user-guides/engagement-record">
The tracker, Risk Group status, linked and reused diligence, and the Risk Summary the Transaction Owner decides on.
</Card>
<Card title="Clause packs and non-standard contracts" icon="file-shield" href="/user-guides/clause-pack">
The clauses an engagement's risk results require, whether the draft has them, and the obligations monitored after signature.
</Card>
<Card title="Monitoring plans" icon="calendar-check" href="/user-guides/monitoring-plans">
The cadence matrix, signal re-timing, IRQ refresh with its diff, owner attestation and performance scorecards.
</Card>
<Card title="Offboarding and continuity" icon="right-from-bracket" href="/user-guides/offboarding-and-continuity">
The executed contract handoff, continuity plans, and an exit plan that closes only on approved evidence.
</Card>
<Card title="Certificate Vault and prequalification" icon="certificate" href="/user-guides/certificate-vault">
Every certificate in one place, prequalification rule sets that can block purchase orders, and licensed ratings in Radar.
</Card>
<Card title="Integration Hub" icon="plug" href="/user-guides/integration-hub">
Coupa, SAP Ariba, Ironclad, Icertis and Microsoft Teams: authentication, field mappings, the sync log and the steward queue.
</Card>
<Card title="Warehouse data share" icon="database" href="/user-guides/warehouse-data-share">
Push your program's tables to Snowflake, Amazon S3 or BigQuery on a schedule.
</Card>
<Card title="Program Insights" icon="chart-pie" href="/user-guides/program-insights">
Program Overview: KPIs, residual risk by business unit and domain, the pre-contract pipeline, slicers, drill-downs and exports.
</Card>
<Card title="Agent Ledger" icon="book-bookmark" href="/user-guides/agent-ledger">
Every agent action and the human decision on it, agent policies, redaction before model calls, and learning from your reviewers.
</Card>
</CardGroup>
## Assessing a vendor
The assessment is the center of the platform, so it gets the most pages: the full walkthrough, a cheat sheet to keep open beside it, the questionnaire mechanics, the packaged inherent risk templates, how web evidence is vetted, and the lightweight run for vendors that do not warrant the full treatment.
<CardGroup>
<Card title="How to run an assessment" icon="list-check" href="/user-guides/running-an-assessment">
The complete lifecycle, screen by screen. Getting the vendor in, creating the assessment from a plan, collecting evidence five different ways, working the issues, follow-up cycles, domain reviews, and the final export.
</Card>
<Card title="Assessment quick reference" icon="bolt" href="/user-guides/assessment-quick-reference">
The cheat sheet. Five steps, quick tips, common scenarios, a troubleshooting table, and the control frameworks at a glance.
</Card>
<Card title="Questionnaires" icon="clipboard-question" href="/user-guides/questionnaires">
Build a template, set conditional logic and internal-only questions, write answers back to the record, assign reviewers, send it to a vendor, and work a submission through to a decision.
</Card>
<Card title="The IRQ library" icon="clipboard-list" href="/user-guides/irq-library">
The six inherent risk questionnaires Coverbase ships: every question each one asks, how the score is calculated, and how to pick and tailor the right starting point.
</Card>
<Card title="Confirm inherent risk before a reassessment" icon="user-check" href="/user-guides/reassessment-irq-review">
Send the relationship owner last cycle's IRQ answers before a reassessment starts, review what changed, and let the plan pick questionnaires from the refreshed inherent risk.
</Card>
<Card title="Evidence quality and source credibility" icon="shield-check" href="/user-guides/evidence-quality">
How every web page is graded for publisher accountability, where you set the minimum bar, what appears on evidence cards and in the Excel export, and exactly which parts of the platform this covers.
</Card>
<Card title="Zero Touch Assessment guide" icon="wand-magic-sparkles" href="/user-guides/zero-touch-assessments">
A triage run assembled entirely from open-source research, with no outreach. How to run one across a portfolio, read the composite and its components, correct a run that bound the wrong company, and read the audit trail.
</Card>
</CardGroup>
Jump straight to a part: [get the vendor in](/user-guides/running-an-assessment#part-1-get-the-vendor-into-coverbase) · [create the assessment](/user-guides/running-an-assessment#part-2-create-the-assessment) · [collect the evidence](/user-guides/running-an-assessment#part-3-collect-the-evidence) · [work the issues](/user-guides/running-an-assessment#part-5-work-the-issues) · [follow-up cycles](/user-guides/running-an-assessment#part-6-run-follow-up-cycles) · [complete and export](/user-guides/running-an-assessment#part-8-complete-and-export) · [triage new requests](/user-guides/analyst-reviewer#step-1-triage-new-vendor-requests) · [review the results](/user-guides/analyst-reviewer#step-3-review-the-results) · [correct the AI](/user-guides/analyst-reviewer#step-4-correct-the-ai)
Questionnaires, evidence and Zero Touch: [building the template](/user-guides/questionnaires#building-the-template) · [conditional logic](/user-guides/questionnaires#conditional-logic) · [write-back rules](/user-guides/questionnaires#write-back-answers-that-update-the-record) · [assigning reviewers](/user-guides/questionnaires#assigning-reviewers) · [reviewing a submission](/user-guides/questionnaires#reviewing-a-submission) · [choosing an IRQ template](/user-guides/irq-library#choosing-a-starting-point) · [the credibility scale](/user-guides/evidence-quality#the-credibility-scale) · [where you set the bar](/user-guides/evidence-quality#where-you-set-the-bar) · [running a Zero Touch assessment](/user-guides/zero-touch-assessments#running-one) · [reading the result](/user-guides/zero-touch-assessments#reading-a-result) · [reviewing a run](/user-guides/zero-touch-assessments#reviewing-a-run)
<Card title="Document library" icon="folder-open" href="/products/document-library">
Where the **Coverbase library documents** on every vendor came from, how they are reviewed before they appear, and why nothing your organization uploads is ever added to them. This page sits with the product pages rather than here.
</Card>
## Findings and obligations
Two records that look alike and answer different questions. A finding is a problem on the vendor's side. An obligation is work your organization owes because of the vendor.
<CardGroup>
<Card title="Findings and remediation" icon="flag" href="/user-guides/findings-and-remediation">
What happens after a finding exists: the Findings page, the statuses and how commitments set them, asking a vendor for a commitment through the portal, verifying the work, findings settings, and where findings show up elsewhere.
</Card>
<Card title="Obligations" icon="list-check" href="/user-guides/obligations">
How obligations are extracted from SOC reports and contracts, the list and the record, what each status means, assigning an owner, asking a business unit to acknowledge one, and where obligations feed the risk register and workflows.
</Card>
</CardGroup>
Jump straight to an answer: [how a finding gets raised](/user-guides/findings-and-remediation#how-a-finding-gets-raised) · [finding statuses](/user-guides/findings-and-remediation#statuses) · [requesting a commitment](/user-guides/findings-and-remediation#requesting-one) · [working a commitment](/user-guides/findings-and-remediation#working-a-commitment) · [findings settings](/user-guides/findings-and-remediation#findings-settings) · [turning on automatic extraction](/user-guides/obligations#turning-on-automatic-extraction) · [obligation statuses](/user-guides/obligations#statuses) · [reviewing extracted obligations](/user-guides/obligations#reviewing-extracted-obligations) · [asking a business unit to acknowledge](/user-guides/obligations#asking-a-business-unit-to-acknowledge)
## Checking a vendor without contacting them
The Vendor Intelligence section on a vendor is a set of tabs, each assembled from public sources without contacting the vendor, and each designed to be checked rather than trusted. There is one guide per tab below, plus the older combined walkthrough the first four replaced.
<CardGroup>
<Card title="Corporate registrations guide" icon="building-columns" href="/user-guides/corporate-registrations">
Whether there is a real, currently registered company behind the vendor, and whether it is the one you think it is. How to read a match verdict, and what a dissolved status means on a vendor you are paying.
</Card>
<Card title="People intelligence guide" icon="users" href="/user-guides/people-intelligence">
Who runs the vendor, and what adverse-media screening found about them. Why confirmed and unconfirmed names are counted differently, and why "not screened" is never the same as "nothing found".
</Card>
<Card title="Financial health guide" icon="chart-line" href="/user-guides/financial-health-score">
How likely the vendor is to still be trading. What the confidence tier tells you about the number, and how private companies with no filings are scored.
</Card>
<Card title="Security intelligence guide" icon="shield-halved" href="/user-guides/security-intelligence">
The outside-in security rating measured against the vendor's own infrastructure. What each factor covers, and what a not-measured factor does and does not tell you.
</Card>
<Card title="Sanctions screening guide" icon="scale-balanced" href="/user-guides/sanctions-screening">
Whether the vendor or its people appear on a sanctions, watchlist, criminal or legal source, re-checked on a schedule rather than once at onboarding. Why the confidence score measures identity and not severity, and how to clear a false positive.
</Card>
<Card title="Screening coverage and sources" icon="list" href="/user-guides/screening-coverage">
Every source screening checks: the sanctions and watchlists, PEP roles, criminal and legal records, adverse media categories, monitoring cadence, and what Coverbase configures on request.
</Card>
<Card title="Financial health and security intelligence" icon="gauge-high" href="/user-guides/vendor-fact-sheet">
The older combined walkthrough, covering the Financial Health Score and External Security Intelligence cards as they appear on the fact sheet. The two dedicated guides above go deeper.
</Card>
</CardGroup>
Jump straight to an answer: [read the registry verdict first](/user-guides/corporate-registrations#read-the-verdict-before-the-identifiers) · [a dissolved status](/user-guides/corporate-registrations#what-to-do-with-a-dissolved-status) · [confirmed and unconfirmed people](/user-guides/people-intelligence#confirmed-and-unconfirmed) · [no findings versus not screened](/user-guides/people-intelligence#no-findings-and-not-screened) · [what the financial tier is worth](/user-guides/financial-health-score#the-tier-tells-you-what-the-number-is-worth) · [runway and burn](/user-guides/financial-health-score#runway-and-burn-for-private-companies) · [the rating is a floor](/user-guides/security-intelligence#the-rating-is-a-floor-not-a-verdict) · [next steps](/user-guides/security-intelligence#next-steps) · [since last scan](/user-guides/security-intelligence#since-last-scan) · [lookalike domains](/user-guides/security-intelligence#lookalike-domains) · [identity confidence is not severity](/user-guides/sanctions-screening#identity-confidence-is-not-severity) · [deciding a match](/user-guides/sanctions-screening#deciding) · [screening settings](/user-guides/sanctions-screening#settings)
## Monitoring between assessments
Radar watches your vendors in the gap between reviews. Sources collect, detectors decide what deserves an alert, and signals land in a queue for someone to triage.
<CardGroup>
<Card title="Working Radar signals" icon="satellite-dish" href="/user-guides/radar-signals">
The vocabulary, the signal queue and its statuses, triaging a signal into a case, a finding or a reassessment, keeping sources and detectors tuned, and where a signal goes next.
</Card>
<Card title="Black Kite monitoring guide" icon="shield-halved" href="/user-guides/black-kite-monitoring">
How to connect your Black Kite portfolio, choose which vendors are watched, and turn known exploited vulnerabilities and focus tags into alerts.
</Card>
<Card title="Bills of materials" icon="boxes-stacked" href="/user-guides/bill-of-materials">
How to upload a vendor's SBOM, keep the right version applied, and get an alert when a known exploited vulnerability affects one of its components.
</Card>
<Card title="Breach notification monitoring guide" icon="file-shield" href="/user-guides/breach-notification-monitoring">
How to watch state attorney general breach registries and SEC cyber incident filings, and turn a filing that names your vendor into an alert.
</Card>
<Card title="Natural hazard monitoring guide" icon="house-flood-water" href="/user-guides/natural-hazard-monitoring">
How to watch earthquakes, storms, floods, wildfires and severe weather warnings, and get an alert when one reaches the location of a vendor's site.
</Card>
<Card title="Dark web monitoring guide" icon="mask" href="/user-guides/dark-web-monitoring">
How Coverbase watches your organization and your vendors on ransomware leak sites, breach catalogs, infostealer logs and lookalike domains, which sources need a license, and how to triage the exposure queue without reading an empty one as clean.
</Card>
</CardGroup>
Jump straight to a step: [the vocabulary](/user-guides/radar-signals#the-vocabulary) · [the signal queue](/user-guides/radar-signals#the-signal-queue) · [triaging a signal](/user-guides/radar-signals#triaging-a-signal) · [sources](/user-guides/radar-signals#sources) · [detectors](/user-guides/radar-signals#detectors) · [testing a detector before you enable it](/user-guides/radar-signals#testing-before-you-enable) · [which vendors are watched](/user-guides/radar-signals#which-vendors-are-watched) · [connect Black Kite credentials](/user-guides/black-kite-monitoring#step-1-connect-your-credentials) · [fix a vendor that will not match](/user-guides/black-kite-monitoring#fixing-a-vendor-that-will-not-match) · [upload an SBOM](/user-guides/bill-of-materials#uploading-a-bill-of-materials) · [how an SBOM is matched](/user-guides/bill-of-materials#how-a-component-is-matched) · [what breach monitoring covers](/user-guides/breach-notification-monitoring#what-coverbase-monitors) · [add the breach sources](/user-guides/breach-notification-monitoring#step-1-add-the-sources) · [how a hazard reaches a vendor](/user-guides/natural-hazard-monitoring#how-a-hazard-reaches-a-vendor)
Radar signals also land in the analyst's queue, and working them is [step 8 of the analyst guide](/user-guides/analyst-reviewer#step-8-work-radar-signals). Setting Radar up in the first place is [step 9 of the admin guide](/user-guides/admin-setup#step-9-configure-radar-continuous-monitoring).
## Risk
The Risk module holds the register, the dependency chain, scenarios, exposure and the board report. The geography map lives under the same entry.
<CardGroup>
<Card title="The Risk module: register, signals and scenarios" icon="triangle-exclamation" href="/user-guides/risk-register">
Score a risk on the 5x5, let findings, contracts and Radar feed it as signals, decide on what the agent proposes, trace the dependency chain, run a what-if scenario, and produce the board pack.
</Card>
<Card title="Risk geography map" icon="map-location-dot" href="/user-guides/risk-geography-map">
Where your suppliers are, which metros they pile up in, and how to narrow the map with the same vendor filters you use on the vendor list. Also covers why archived suppliers are hidden by default.
</Card>
</CardGroup>
Jump straight to an answer: [reading the register](/user-guides/risk-register#reading-the-register) · [creating a risk](/user-guides/risk-register#creating-a-risk) · [signal sources and thresholds](/user-guides/risk-register#signal-sources-and-thresholds) · [the agent](/user-guides/risk-register#the-agent) · [the chain](/user-guides/risk-register#chain) · [simulate a scenario](/user-guides/risk-register#simulate) · [the board report](/user-guides/risk-register#report) · [configuring the module](/user-guides/risk-register#configuring-the-module) · [what the two map layers mean](/user-guides/risk-geography-map#what-the-map-draws) · [filtering the map](/user-guides/risk-geography-map#filtering-the-map) · [many suppliers at one address](/user-guides/risk-geography-map#many-suppliers-at-one-address)
## Contracts
Start with the workspace guide to learn the screens. Then it splits four ways: getting a contract in (intake and the repository), what a contract *is* (components and dates), what its *language* says (Contract Guardian and negotiation rounds), and what *values* to pull out of it (Document Insights, under Documents below).
<CardGroup>
<Card title="Contracts workspace" icon="folder-open" href="/user-guides/contracts-workspace">
The screens you work in every day. The attention cards, the table and renewal runway views of the list, and the cards on a contract record.
</Card>
<Card title="Contract intake and approval" icon="clipboard-check" href="/user-guides/contract-intake-and-approval">
Raise a contract request from a vendor, confirm what the AI read off the draft, route it through your approval chain, and send the approved agreement to DocuSign.
</Card>
<Card title="Contract Assembly" icon="layer-group" href="/user-guides/contract-assembly">
Import a folder of contracts you already hold. Coverbase groups the documents that belong together, proposes a vendor and a contract for each group, and asks the questions it will not answer for you. Nothing is created until you confirm.
</Card>
<Card title="The contracts repository" icon="inbox" href="/user-guides/contracts-repository">
Forward an agreement to your organization's paralegal inbox, and let Coverbase name, deduplicate, version and file it. The inbox log, the folder schemes and the settings behind the address.
</Card>
<Card title="Contract components" icon="puzzle-piece" href="/user-guides/contract-components">
The catalog. Every component Coverbase reads a contract into, what it interprets each one as, which contract fields it may answer, and what happens when two documents claim the same one.
</Card>
<Card title="Contract dates and reminders" icon="calendar-days" href="/user-guides/contract-dates-and-reminders">
The contract timeline. What each date means, which ones Coverbase calculates and why they cannot be cleared, who gets the reminder emails, and how to turn a reminder off for a single contract.
</Card>
<Card title="The contract Spend tab" icon="coins" href="/user-guides/contract-spend">
What a contract costs. The priced lines read from its documents or added by hand, how the annual total is worked out, why currencies are never converted, spend across renewals, and other contracts in the same category.
</Card>
<Card title="Negotiation rounds" icon="arrow-right-arrow-left" href="/user-guides/contract-negotiation-rounds">
Upload the marked-up contract a vendor sends back, see what they changed, which of your asks they accepted, and what they edited without being asked, without starting the clause review over.
</Card>
</CardGroup>
### Clause review with Contract Guardian
<CardGroup>
<Card title="Contract Guardian guide" icon="file-contract" href="/user-guides/contract-guardian">
Build a clause set from the packaged library or from your own template contract, write the risk-tier variants that define acceptable, negotiable and unacceptable language, then run reviews and triage the deviations.
</Card>
<Card title="The clause set library" icon="book-open" href="/user-guides/clause-set-library">
The 12 packaged clause standards Coverbase ships, from Enterprise SaaS to HIPAA to Payments. What each one covers, which clauses would block a signature, and how to choose a starting point.
</Card>
<Card title="Generate a clause set from your own contract" icon="wand-magic-sparkles" href="/user-guides/baseline-contract-extraction">
Upload your template MSA or DPA and let Coverbase extract a clause set from it. What extraction gives you, why it drops language it cannot quote, and the tiering you still have to write yourself.
</Card>
<Card title="Import and export clause sets as spreadsheets" icon="file-import" href="/user-guides/clause-set-spreadsheet-import">
Already have your clause playbook in Excel? The workbook format, every column explained, what happens when you re-upload a file, and how to export a set back out to branch it.
</Card>
</CardGroup>
Jump straight to an answer: [the contracts list page](/user-guides/contracts-workspace#the-contracts-list-page) · [the contract record](/user-guides/contracts-workspace#the-contract-record) · [raising a request](/user-guides/contract-intake-and-approval#raising-a-request) · [the approval chain](/user-guides/contract-intake-and-approval#the-approval-chain) · [sending for signature](/user-guides/contract-intake-and-approval#sending-for-signature) · [forwarding an agreement](/user-guides/contracts-repository#forwarding-an-agreement) · [how a document is filed](/user-guides/contracts-repository#how-a-document-is-filed) · [the inbox log](/user-guides/contracts-repository#the-inbox-log) · [the component catalog](/user-guides/contract-components#the-catalogue) · [correcting what a document carries](/user-guides/contract-components#correcting-what-a-document-carries) · [fixed versus calculated dates](/user-guides/contract-dates-and-reminders#fixed-dates-versus-calculated-dates) · [who gets reminded](/user-guides/contract-dates-and-reminders#who-gets-reminded-and-when) · [mute one contract](/user-guides/contract-dates-and-reminders#turning-off-a-reminder-for-one-contract)
On clause review: [build your clause set](/user-guides/contract-guardian#step-2-build-your-clause-set) · [write risk-tier variants](/user-guides/contract-guardian#step-4-write-your-risk-tier-variants) · [run a review](/user-guides/contract-guardian#step-6-run-a-review) · [work the results](/user-guides/contract-guardian#step-7-work-the-results) · [a workable rollout](/user-guides/contract-guardian#a-workable-rollout) · [upload what the vendor sent back](/user-guides/contract-negotiation-rounds#step-1-upload-what-the-vendor-sent-back) · [see what changed](/user-guides/contract-negotiation-rounds#step-2-see-what-changed) · [choosing a packaged clause set](/user-guides/clause-set-library#choosing-a-starting-point) · [run an extraction](/user-guides/baseline-contract-extraction#run-an-extraction) · [get the spreadsheet template](/user-guides/clause-set-spreadsheet-import#get-the-template)
## Getting it signed
Coverbase signs agreements in the same place it stores them, so the executed copy and the evidence that it happened land on the contract and the vendor without anyone filing them.
<CardGroup>
<Card title="E-signature overview" icon="signature" href="/user-guides/signature-overview">
Start here. The four moving parts, the shape of a signing, the envelope statuses, and the organization-wide settings worth doing once before your first send.
</Card>
<Card title="Signature templates" icon="file-lines" href="/user-guides/signature-templates">
Build an NDA or order form once: the source document, the signing parties as roles rather than people, and the fields each role fills. Plus what freezes a template, and why it is the first send rather than publishing.
</Card>
<Card title="The passage library" icon="book" href="/user-guides/signature-passage-library">
The clauses, party blocks and signature pages your team reuses, Coverbase's nine starter passages, and writing an agreement in Coverbase with **Insert passage** instead of uploading one.
</Card>
<Card title="Sending for signature" icon="paper-plane" href="/user-guides/signature-envelopes">
The four-step send wizard, routing order and access codes, tracking what is out, correcting or voiding an envelope, and the hash-chained audit trail.
</Card>
<Card title="Bulk send" icon="users" href="/user-guides/signature-bulk-send">
One published template to a list of parties, one envelope per row. The list format, prefilled fields, what each party receives, and tracking or canceling a batch.
</Card>
<Card title="The signing experience" icon="pen-nib" href="/user-guides/signature-signing-experience">
The counterparty's side: consent, filling, adopting one signature that covers every block, and the executed copy they keep. Plus how to brand the portal as yours.
</Card>
</CardGroup>
Jump straight to an answer: [an envelope's statuses](/user-guides/signature-overview#an-envelopes-statuses) · [before your first send](/user-guides/signature-overview#before-your-first-send) · [what the field types do](/user-guides/signature-templates#what-the-field-types-do) · [versioning](/user-guides/signature-templates#versioning-what-freezes-and-when) · [the recipients step](/user-guides/signature-envelopes#step-2-the-recipients) · [nudging, correcting, canceling](/user-guides/signature-envelopes#nudging-correcting-cancelling) · [the audit trail](/user-guides/signature-envelopes#the-audit-trail) · [what to tell a signer who is stuck](/user-guides/signature-signing-experience#what-to-tell-a-signer-who-is-stuck)
## Documents
Three guides about the documents on a vendor: the values Coverbase pulls out of every one, asking them a question in chat, and the reminders that fire before one lapses.
<CardGroup>
<Card title="Document Insights guide" icon="file-magnifying-glass" href="/user-guides/document-insights">
Field-level extraction. Define the values Coverbase pulls out of every document (dates, caps, notice periods, governing law), with a starter library to copy and a straight answer on when to use Extract versus Synthesize.
</Card>
<Card title="Asking your documents a question" icon="comment-dots" href="/user-guides/document-evidence-pull">
Ask a plain-English question in chat and get back the passage from a vendor's documents that answers it: the verbatim quote, its page, a cropped image of the passage, and a link that opens the document with it marked.
</Card>
<Card title="Document expiry reminders" icon="bell" href="/user-guides/document-expiry-reminders">
How Coverbase reminds you before a vendor document lapses: which dates it fires from, who receives the email, and where to see everything that is expiring.
</Card>
</CardGroup>
Jump straight to an answer: [Extract versus Synthesize](/user-guides/document-insights#extract-vs-synthesize) · [a starter library](/user-guides/document-insights#a-starter-library) · [auditing coverage](/user-guides/document-insights#auditing-coverage) · [backfilling history](/user-guides/document-insights#backfilling-history) · [what you get back from a question](/user-guides/document-evidence-pull#what-you-get-back) · [what can and cannot be read](/user-guides/document-evidence-pull#what-can-and-cannot-be-read) · [when the expiry reminder fires](/user-guides/document-expiry-reminders#when-the-reminder-fires) · [who receives it](/user-guides/document-expiry-reminders#who-receives-it)
## Workflows and automation
Automations that react when a record changes: the ready-made templates, and building your own from a trigger, conditions and an action.
<CardGroup>
<Card title="Workflow templates" icon="wand-magic-sparkles" href="/user-guides/workflow-templates">
The nineteen ready-to-run automations Coverbase ships: what each one does, which modules it needs, what you have to change before turning it on, and how to make one your own.
</Card>
<Card title="Building a workflow" icon="diagram-project" href="/user-guides/building-a-workflow">
Pick a trigger, narrow it with conditions, configure the action, use placeholders, test it, switch it on, then read the runs and the work queue items it produces.
</Card>
<Card title="ServiceNow workflow actions" icon="server" href="/user-guides/servicenow-workflow-actions">
Create and update linked ServiceNow records, file one record per issue or finding, send a custom request, and upload documents from a workflow step.
</Card>
</CardGroup>
Jump straight to an answer: [the nineteen templates](/user-guides/workflow-templates#the-nineteen-templates) · [which modules a template needs](/user-guides/workflow-templates#which-modules-a-template-needs) · [applying a template](/user-guides/workflow-templates#applying-one) · [creating a workflow from scratch](/user-guides/building-a-workflow#creating-a-workflow-from-scratch) · [building an automation](/user-guides/building-a-workflow#building-an-automation) · [placeholders in action text](/user-guides/building-a-workflow#placeholders-in-action-text) · [creating a work queue item](/user-guides/building-a-workflow#creating-a-work-queue-item) · [reading the runs page](/user-guides/building-a-workflow#reading-the-runs-page) · [working the work queue](/user-guides/building-a-workflow#working-the-work-queue)
## Dashboards and reporting
What the program looks like from above, drawn live from your own records, and the documents you hand to someone else.
<CardGroup>
<Card title="Dashboards and the chart library" icon="chart-line" href="/user-guides/dashboard-library">
The 15 dashboards and 110 charts Coverbase ships ready to use: a board overview, a cycle-time and SLA view, contract spend and renewals, savings, intake demand, control assurance, tag coverage, findings and Radar triage. Every one is a copy you own and can edit.
</Card>
<Card title="Exporting and scheduling dashboards" icon="file-export" href="/user-guides/dashboard-exports">
Export any dashboard to PDF or Excel, or email it on a schedule with the files attached or the charts drawn into the message. What each chart type becomes, when the email goes, who can manage a schedule, and what happens when a recipient leaves.
</Card>
<Card title="Reporting overview" icon="file-lines" href="/reporting/overview">
The two kinds of assessment deliverable: standard exports, and custom Word report templates filled from live assessment data. Which one to use, and how a custom report is generated.
</Card>
<Card title="Custom Word report templates" icon="file-word" href="/reporting/assessment-report-templates">
Author the branded `.docx`: placeholder syntax, AI-written sections, repeating findings tables, and signature anchors.
</Card>
<Card title="Placeholder reference" icon="brackets-curly" href="/reporting/template-placeholders">
Every vendor, assessment, service, review and finding placeholder, with its resolved value and formatting.
</Card>
<Card title="Evidence packaging and the due-diligence file" icon="box-archive" href="/reporting/due-diligence-file">
Produce the complete file for one third party, and assemble an examination package.
</Card>
</CardGroup>
Jump straight to an answer: [the ready-made dashboards](/user-guides/dashboard-library#the-ready-made-dashboards) · [every dashboard in detail](/user-guides/dashboard-library#every-dashboard-in-detail) · [what is on each shelf](/user-guides/dashboard-library#what-is-on-each-shelf) · [making them yours](/user-guides/dashboard-library#making-them-yours) · [which report to use](/reporting/overview#which-one-to-use) · [how a custom report is generated](/reporting/overview#how-a-custom-report-is-generated)
## Sourcing and RFPs
Vendor selection with risk and compliance evaluation built into it rather than bolted on afterwards. The product page behind this is [RFP Platform](/products/rfp-platform).
<Card title="How to run an RFP" icon="clipboard-list" href="/user-guides/running-an-rfp">
One sourcing event end to end. Draft the RFP with the AI wizard, compare the field without contacting anyone, score responses against your rubric with evidence attached, read the pricing side by side, and record the decision in a memo somebody can read a year later.
</Card>
Jump straight to a part: [draft the RFP](/user-guides/running-an-rfp#part-1-draft-the-rfp) · [run it without outreach](/user-guides/running-an-rfp#part-3-run-it-without-outreach) · [score the responses](/user-guides/running-an-rfp#part-4-score-the-responses) · [compare and decide](/user-guides/running-an-rfp#part-5-compare-and-decide) · [run an RFP from chat](/user-guides/running-an-rfp#running-an-rfp-from-chat)
## Internal controls
Coverbase against your own applications, with the same findings, workflows and reporting as third-party risk.
<Card title="Internal controls monitoring with Inspect" icon="building-shield" href="/user-guides/internal-controls-monitoring">
Connect your applications through Okta, Entra or Google, run an inspection against an internal control set, read the result, watch for drift between runs, keep probes and schedules running, and turn what it finds into findings.
</Card>
Jump straight to a step: [connecting an application](/user-guides/internal-controls-monitoring#connecting-an-application) · [running an inspection](/user-guides/internal-controls-monitoring#running-an-inspection) · [reading an inspection](/user-guides/internal-controls-monitoring#reading-an-inspection) · [drift between runs](/user-guides/internal-controls-monitoring#drift-between-runs) · [probes](/user-guides/internal-controls-monitoring#probes) · [schedules](/user-guides/internal-controls-monitoring#schedules) · [the accounts directory](/user-guides/internal-controls-monitoring#the-accounts-directory)
## The complete directory
Every guide in this section, in one table.
| Area | Guide | Who it is for | What it covers |
| - | - | - | - |
| Start here | [Admin and setup guide](/user-guides/admin-setup) | Admin | The eleven setup steps, from importing vendors to enabling obligations extraction |
| Start here | [Analyst and reviewer guide](/user-guides/analyst-reviewer) | Analyst | The nine-step daily loop: triage, assess, review, correct, follow up, disposition |
| Start here | [Requesting a new vendor](/user-guides/requesting-a-vendor) | Requester | Filing a request in the portal or in chat, and what happens after you submit |
| Setup | [Configuring your data model](/user-guides/data-model-configuration) | Admin | Custom fields on nine object types, statuses, approval options, scales, risk domains, terminology, relationships and automations |
| Setup | [Permissions and roles](/user-guides/permissions-and-roles) | Admin | The six default roles, how a permission is built, and how to build and assign a custom role |
| Setup | [Assignment, delegation and out of office](/user-guides/assignment-and-delegation) | Admin | User groups, round-robin and assign-to-all routing, out-of-office windows, reassignment, and the assignment log |
| Setup | [Reviews, approvals and gates](/user-guides/reviews-and-approvals) | Admin | Gate outcomes, parallel domain-scoped SME reviews, multi-approver logic, and return-for-rework loops |
| Setup | [Email and notifications](/user-guides/email-notifications) | Admin | Every email the platform sends, who receives it, the four layouts, and your branding |
| Setup | [White-labeling your vendor-facing domain](/user-guides/white-labeling) | Admin | Sending vendor email and hosting the portal on your own subdomain |
| Setup | [Webhooks](/user-guides/webhooks) | Admin, IT | Adding endpoints, choosing events, the signing secret, test events, delivery history and retries |
| Vendors | [The vendor record](/user-guides/vendor-record) | Anyone | The vendor list and page, services and engagements, subprocessors, owners, custom fields, tags and archiving |
| Vendors | [Supplier information guide](/user-guides/supplier-information) | Procurement, finance | Bank details, addresses, tax registrations, and the review that stops fraud |
| Vendors | [Supplier countries](/user-guides/supplier-countries/overview) | Procurement, finance | All 109 validated countries, with the exact fields, formats and check digits |
| Vendors | [Centralized supplier portal](/user-guides/centralized-supplier-portal) | Admin, procurement | Turning the portal on, choosing its sections, and what suppliers may change or must have approved |
| Vendors | [The supplier portal, for suppliers](/user-guides/supplier-portal-for-suppliers) | Suppliers | Signing in, what is on the page, keeping details current, and adding colleagues |
| Third-party lifecycle | [Intake Agent](/user-guides/intake-agent) | Admin, TPRM Office | Slack, Teams, email and MCP channels, and the agent's conversations |
| Third-party lifecycle | [Front Door triage](/user-guides/front-door-triage) | TPRM Office, Supply Chain | Identifier matching, reuse by domain, dual sign-off, IRQ scoping rules, Do Not Use, budget and material change |
| Third-party lifecycle | [Risk methodology](/user-guides/risk-methodology) | Admin, TPRM Office | Weights, aggregation, the reviewer matrix, escalation, questionnaire versions, and score overrides |
| Third-party lifecycle | [Due diligence methods and the portal](/user-guides/due-diligence-methods-and-portal) | Risk Groups | Assessment methods, review sessions, delegation, carry-forward, edit approval, service-level sends |
| Third-party lifecycle | [Claim check](/user-guides/claim-check) | Risk Groups | Running a check, verdicts and cited evidence, raising findings and asking the vendor |
| Third-party lifecycle | [The issue acceptance chain](/user-guides/issue-acceptance-chain) | TPRM Office, Risk Groups | Routing rules, proposal, recommendation, decision, extended approval, bulk decisions |
| Third-party lifecycle | [The engagement record](/user-guides/engagement-record) | Transaction Owner, TPRM Office | The tracker, Risk Groups, linked diligence, the Risk Summary, the decision, notices |
| Third-party lifecycle | [Clause packs and non-standard contracts](/user-guides/clause-pack) | Legal, TPRM Office | Clause rules by risk domain, the engagement's pack, obligations after signature, the non-standard report |
| Third-party lifecycle | [Monitoring plans](/user-guides/monitoring-plans) | TPRM Office, Transaction Owner | The cadence matrix, signals, IRQ refresh, owner attestation, scorecards |
| Third-party lifecycle | [Offboarding and continuity](/user-guides/offboarding-and-continuity) | TPRM Office, Supply Chain, Transaction Owner | Contract handoff, continuity plans, offboarding, the exit plan and the destruction certificate |
| Third-party lifecycle | [Certificate Vault and prequalification](/user-guides/certificate-vault) | Analyst, procurement | The vault, requesting certificates, networks, rule sets, overrides, licensed ratings |
| Third-party lifecycle | [Integration Hub](/user-guides/integration-hub) | Admin, IT | Connecting procurement, contract and messaging systems, mappings, the sync log, the steward queue |
| Third-party lifecycle | [Warehouse data share](/user-guides/warehouse-data-share) | Admin, data teams | Snowflake, S3 and BigQuery destinations, the run log and the table contract |
| Third-party lifecycle | [Program Insights](/user-guides/program-insights) | TPRM Office, leadership | Levels, slicers, the KPIs, the heat grid, the pipeline, drill-downs, export and the board pack |
| Third-party lifecycle | [Agent Ledger](/user-guides/agent-ledger) | Admin, model risk | The ledger, decisions, agent policies, redaction, learning and the audit export |
| Assessments | [How to run an assessment](/user-guides/running-an-assessment) | Analyst | The full lifecycle in eight parts, from getting the vendor in to the final export |
| Assessments | [Assessment quick reference](/user-guides/assessment-quick-reference) | Analyst | A one-page cheat sheet: five steps, common scenarios, troubleshooting |
| Assessments | [Questionnaires](/user-guides/questionnaires) | Admin, analyst | Templates, question types, conditional logic, write-back, reviewers, sending, and reviewing a submission |
| Assessments | [The IRQ library](/user-guides/irq-library) | Admin | The six packaged inherent risk questionnaires, how the score works, and tailoring your copy |
| Assessments | [Confirm inherent risk before a reassessment](/user-guides/reassessment-irq-review) | Admin, analyst | Turning the check on for a plan, the relationship owner's prefilled IRQ, reviewing changes, and skipping |
| Assessments | [Evidence quality and source credibility](/user-guides/evidence-quality) | Admin, analyst | How web evidence is graded, where you set the minimum bar, and what gets discarded |
| Assessments | [Zero Touch Assessment guide](/user-guides/zero-touch-assessments) | Analyst | Running a no-outreach triage assessment across a portfolio and reading the score |
| Findings and obligations | [Findings and remediation](/user-guides/findings-and-remediation) | Analyst | Finding statuses, vendor commitments through the portal, verification, and findings settings |
| Findings and obligations | [Obligations](/user-guides/obligations) | Analyst, control owners | Extraction from SOC reports and contracts, statuses, ownership, and business-unit acknowledgement |
| Vendor intelligence | [Corporate registrations guide](/user-guides/corporate-registrations) | Analyst | Whether a real, currently registered company sits behind the vendor |
| Vendor intelligence | [People intelligence guide](/user-guides/people-intelligence) | Analyst | Who runs the vendor, and what adverse-media screening found about them |
| Vendor intelligence | [Financial health guide](/user-guides/financial-health-score) | Analyst | How likely the vendor is to still be trading, and what the confidence tier means |
| Vendor intelligence | [Security intelligence guide](/user-guides/security-intelligence) | Analyst | The outside-in security rating, factor by factor |
| Vendor intelligence | [Sanctions screening guide](/user-guides/sanctions-screening) | Analyst, compliance | Continuous sanctions and watchlist screening, and how to clear a match |
| Vendor intelligence | [Screening coverage and sources](/user-guides/screening-coverage) | Admin, compliance | Every list, PEP role and adverse media category screening checks, and the options Coverbase configures on request |
| Vendor intelligence | [Financial health and security intelligence](/user-guides/vendor-fact-sheet) | Analyst | The older combined walkthrough of both cards on the vendor fact sheet |
| Monitoring | [Working Radar signals](/user-guides/radar-signals) | Analyst, admin | The signal queue, triage, sources, detectors, and where a signal goes next |
| Monitoring | [Black Kite monitoring guide](/user-guides/black-kite-monitoring) | Admin | Feeding your own Black Kite portfolio into Radar signals |
| Monitoring | [Bills of materials](/user-guides/bill-of-materials) | Analyst, admin | Uploading vendor SBOMs, supported formats, versions, and the Radar alerts they raise |
| Monitoring | [Breach notification monitoring guide](/user-guides/breach-notification-monitoring) | Analyst, admin | State attorney general breach registries and SEC filings as Radar sources, and the detector that alerts on them |
| Monitoring | [Natural hazard monitoring guide](/user-guides/natural-hazard-monitoring) | Analyst, admin | Earthquake, storm, flood, wildfire and severe weather feeds matched to vendors by the location of their sites |
| Monitoring | [Dark web monitoring guide](/user-guides/dark-web-monitoring) | Analyst, admin | The daily sweep, what is watched and from which sources, triaging the exposure queue, and the vendor's Dark Web tab |
| Risk | [The Risk module](/user-guides/risk-register) | Risk, admin | The register, signals, the agent, the chain, scenarios, exposure and the board report |
| Risk | [Risk geography map](/user-guides/risk-geography-map) | Analyst, risk | Where your suppliers are, and filtering the map like the vendor list |
| Contracts | [Contracts workspace](/user-guides/contracts-workspace) | Anyone | The statistics row, the renewal runway, and the cards on a contract |
| Contracts | [Contract intake and approval](/user-guides/contract-intake-and-approval) | Legal, procurement | Raising a contract, the approval chain, and sending to DocuSign |
| Contracts | [Contract Assembly](/user-guides/contract-assembly) | Legal, procurement, admin | Bulk importing contracts you already hold: grouping, vendor matching, the review's questions, and confirming |
| Contracts | [The contracts repository](/user-guides/contracts-repository) | Legal, paralegal | The paralegal inbox: forwarding, classification, versioning, folders and the inbox log |
| Contracts | [Contract components](/user-guides/contract-components) | Admin, legal | The catalog of components a contract is read into, and how conflicts resolve |
| Contracts | [Contract dates and reminders](/user-guides/contract-dates-and-reminders) | Anyone | Which dates Coverbase calculates, who gets reminded, and how to mute one contract |
| Contracts | [The contract Spend tab](/user-guides/contract-spend) | Procurement, finance | Priced lines, the annual total, currencies, the renewal series, and overlapping spend |
| Contracts | [Negotiation rounds](/user-guides/contract-negotiation-rounds) | Legal | Reading a vendor's returned markup against what you asked for |
| Contracts | [Contract Guardian guide](/user-guides/contract-guardian) | Legal, admin | Clause sets, risk-tier variants, running reviews, and triaging deviations |
| Contracts | [The clause set library](/user-guides/clause-set-library) | Legal | The 12 packaged clause standards, what each covers, and how to pick one |
| Contracts | [Generate a clause set from your own contract](/user-guides/baseline-contract-extraction) | Legal | Turning your template MSA or DPA into a starting clause set |
| Contracts | [Import and export clause sets as spreadsheets](/user-guides/clause-set-spreadsheet-import) | Legal | The workbook format, every column, and what a re-upload does |
| E-signature | [E-signature overview](/user-guides/signature-overview) | Anyone | How templates, envelopes, the portal and the sealed copy fit together |
| E-signature | [Signature templates](/user-guides/signature-templates) | Legal, admin | Building the paper you send repeatedly, and what freezes a template |
| E-signature | [The passage library](/user-guides/signature-passage-library) | Legal, admin | Reusable clauses and starter passages, and writing an agreement in Coverbase |
| E-signature | [Sending for signature](/user-guides/signature-envelopes) | Anyone | The four-step send wizard, tracking an envelope, and the audit trail |
| E-signature | [Bulk send](/user-guides/signature-bulk-send) | Legal, procurement | One template to a list of parties, the list format, and tracking a batch |
| E-signature | [The signing experience](/user-guides/signature-signing-experience) | Anyone | What your counterparty sees, and how to unstick one who is confused |
| Documents | [Document Insights guide](/user-guides/document-insights) | Admin, legal | Defining the values pulled out of every document, with a starter library to copy |
| Documents | [Asking your documents a question](/user-guides/document-evidence-pull) | Analyst | A plain-English question in chat, answered with the quoted passage and its page |
| Documents | [Document expiry reminders](/user-guides/document-expiry-reminders) | Analyst, admin | Which dates a reminder fires from, who receives it, and where to see what is expiring |
| Workflows | [Workflow templates](/user-guides/workflow-templates) | Admin | The nineteen ready-to-run automations, and what to change before turning one on |
| Workflows | [Building a workflow](/user-guides/building-a-workflow) | Admin | Triggers, conditions, actions, placeholders, runs and the work queue |
| Workflows | [ServiceNow workflow actions](/user-guides/servicenow-workflow-actions) | Admin | Creating and updating linked records, one record per issue or finding, custom requests and document uploads |
| Dashboards and reporting | [Dashboards and the chart library](/user-guides/dashboard-library) | Anyone | The 15 ready-made dashboards and 110 charts, and how to build from them |
| Dashboards and reporting | [Exporting and scheduling dashboards](/user-guides/dashboard-exports) | Anyone, admin | PDF and Excel exports, scheduled dashboard emails, recipients, timing and limits |
| Dashboards and reporting | [Reporting overview](/reporting/overview) | Analyst, admin | Standard exports, custom Word templates, placeholders, and the due-diligence file |
| Sourcing | [How to run an RFP](/user-guides/running-an-rfp) | Sourcing | One sourcing event end to end, from AI-drafted RFP to a decision memo |
| Internal controls | [Internal controls monitoring with Inspect](/user-guides/internal-controls-monitoring) | Security, IT | Connecting applications, inspections, drift, probes, schedules and the accounts directory |
## Reference pages that live outside these guides
Pages every guide points at sooner or later. They sit elsewhere in the documentation because they are reference rather than walkthrough.
<CardGroup>
<Card title="Control Set library" icon="shield-check" href="/control-library">
Both halves of the packaged library and what each set measures: the vendor frameworks to assess a third party against, and the internal sets Inspect evaluates against your own applications.
</Card>
<Card title="Field reference" icon="table-list" href="/fields/overview">
Every filterable field, its path, and where it comes from. The same paths drive saved views, workflow conditions and the query API.
</Card>
<Card title="What each product does" icon="grid-2" href="/products/autonomous-intake">
A page per capability, from Autonomous Intake to internal controls monitoring, for when you want the what and why before the how.
</Card>
</CardGroup>
## How Coverbase thinks
A little context makes everything else click.
<AccordionGroup>
<Accordion title="Document-first, not questionnaire-first" icon="file-magnifying-glass">
Traditional TPRM sends vendors long questionnaires and trusts their self-reported answers. Coverbase works the other way around. It collects the vendor's documents (SOC 2, pen test, ISO certificates, policies, contracts), parses the whole set, and measures that evidence against your controls. Most of what you configure exists to guide that measurement, and questionnaires become a targeted backup for the gaps rather than the starting point.
</Accordion>
<Accordion title="Tags are the routing engine" icon="tags">
When someone requests a vendor, their answers to the intake questionnaire apply tags automatically. Tags then decide which control frameworks apply, which documents are required, which team reviews, and how the vendor is scored. A financial-services vendor handling PHI in the EU gets a different track than a US-only SaaS tool with read-only access, without manual triage.
</Accordion>
<Accordion title="The AI drafts, humans judge" icon="scale-balanced">
A typical assessment measures a hundred-plus controls and surfaces a handful of material issues. The AI does the reading and you do the judging. Every result carries citations to the source language, so when the AI is wrong it is easy to see, and when you correct it, that correction is permanent and applies to every future assessment.
</Accordion>
<Accordion title="Configuration changes are not retroactive" icon="clock-rotate-left">
For auditability, edits to questionnaires and control sets apply going forward. Completed submissions and assessments keep the version they ran on, and a control-set edit creates a new version rather than overwriting the old one. If a new standard has to apply to existing vendors, you run a bulk reassessment. Nothing you have already signed off on changes underneath you.
</Accordion>
</AccordionGroup>
## Looking something up
The questions people arrive with, and the place each one is answered.
| I want to know\... | Go to |
| - | - |
| What do I configure first, and in what order? | [Setup checklist](/user-guides/admin-setup#setup-checklist) |
| How do I get my existing vendors in? | [Import your vendor portfolio](/user-guides/admin-setup#step-2-import-your-vendor-portfolio) |
| Can a supplier see everything we have open with them in one place? | [Turning it on](/user-guides/centralized-supplier-portal#turning-it-on) |
| How do tags decide which controls apply? | [Create your tag structure](/user-guides/admin-setup#step-3-create-your-tag-structure) |
| Who can see what, and how do I build a custom role? | [Building a custom role](/user-guides/permissions-and-roles#building-a-custom-role) |
| How does a review reach a person when the owner is away? | [Out of office](/user-guides/assignment-and-delegation#out-of-office) |
| How do I stop the AI citing a low-quality web page? | [Where you set the bar](/user-guides/evidence-quality#where-you-set-the-bar) |
| Which credibility threshold should I pick? | [Choosing a threshold](/user-guides/evidence-quality#choosing-a-threshold) |
| The AI got a control wrong. How do I fix it for good? | [Correct the AI](/user-guides/analyst-reviewer#step-4-correct-the-ai) |
| How do I chase a vendor for missing evidence? | [Run follow-up cycles](/user-guides/running-an-assessment#part-6-run-follow-up-cycles) |
| How do I check the scope has not changed before a reassessment? | [Confirm inherent risk before a reassessment](/user-guides/reassessment-irq-review) |
| How do I send Coverbase events to our own system? | [Adding an endpoint](/user-guides/webhooks#adding-an-endpoint) |
| How do I file each finding as a ServiceNow risk issue? | [One record per issue or finding](/user-guides/servicenow-workflow-actions#one-record-per-issue-or-finding) |
| Is our organization or a vendor listed on a ransomware leak site? | [What each source checks](/user-guides/dark-web-monitoring#what-each-source-checks) |
| A vendor's Dark Web tab says Clear. Was it checked? | [The vendor's Dark Web tab](/user-guides/dark-web-monitoring#the-vendors-dark-web-tab) |
| How do I import all the contracts we already have? | [Import the files](/user-guides/contract-assembly#import-the-files) |
| Why does a contract's annual spend show a dash? | [How currencies are handled](/user-guides/contract-spend#how-currencies-are-handled) |
| How do I send the same NDA to fifty suppliers at once? | [Send a batch](/user-guides/signature-bulk-send#send-a-batch) |
| Can we keep standard clauses to reuse when writing an agreement? | [Start from the starter passages](/user-guides/signature-passage-library#start-from-the-starter-passages) |
| Can a dashboard email itself to people every week? | [Scheduling a dashboard by email](/user-guides/dashboard-exports#scheduling-a-dashboard-by-email) |
| How do I export the finished assessment? | [Complete and export](/user-guides/running-an-assessment#part-8-complete-and-export) |
| How do I show a question only when an earlier answer needs it? | [Conditional logic](/user-guides/questionnaires#conditional-logic) |
| How do I set up conditional logic for a long questionnaire in one go? | [Importing rules from a spreadsheet](/user-guides/questionnaires#importing-rules-from-a-spreadsheet) |
| Why did a questionnaire answer not update the vendor? | [Write-back: answers that update the record](/user-guides/questionnaires#write-back-answers-that-update-the-record) |
| I added a reviewer and nothing reached their work queue. | [Assigning reviewers](/user-guides/questionnaires#assigning-reviewers) |
| Can we reuse due diligence we already did for a similar engagement? | [Decide reuse and record the disposition](/user-guides/front-door-triage#step-5-decide-reuse-and-record-the-disposition) |
| How do I stop anyone buying from a vendor we must not use? | [Mark vendors you must not use](/user-guides/front-door-triage#step-2-mark-vendors-you-must-not-use) |
| Can one Critical domain make the overall rating High? | [Choose how ratings roll up](/user-guides/risk-methodology#step-2-choose-how-ratings-roll-up) |
| How do I lock an inherent risk questionnaire while it is in use? | [Version your inherent risk questionnaires](/user-guides/risk-methodology#step-5-version-your-inherent-risk-questionnaires) |
| Why can't a vendor submit a questionnaire they finished? | [Carry answers forward](/user-guides/due-diligence-methods-and-portal#carry-answers-forward) |
| Can people request a vendor from Slack or Teams? | [Turn on the channels you want](/user-guides/intake-agent#step-2-turn-on-the-channels-you-want) |
| Does the vendor's SOC report back up their answers? | [Read the verdicts](/user-guides/claim-check#step-2-read-the-verdicts) |
| Which contracts depart from our standard clauses? | [Use the Non-standard Contracts report](/user-guides/clause-pack#step-4-use-the-non-standard-contracts-report) |
| Who has to sign off before we accept a finding's risk? | [How the chain works](/user-guides/issue-acceptance-chain#how-the-chain-works) |
| When will the Transaction Owner get a decision? | [Open the engagement](/user-guides/engagement-record#step-2-open-the-engagement) |
| How often does each tier need a scorecard or attestation? | [Set the methodology](/user-guides/monitoring-plans#step-1-set-the-methodology) |
| How do we prove a vendor destroyed our data? | [Get the vendor's destruction certificate](/user-guides/offboarding-and-continuity#get-the-vendors-destruction-certificate) |
| Which vendors are blocked by prequalification? | [Override a result](/user-guides/certificate-vault#step-5-override-a-result) |
| A Coupa supplier did not link to our vendor. | [Work the steward queue](/user-guides/integration-hub#step-6-work-the-steward-queue) |
| Can our risk data land in our own Snowflake? | [Add the destination](/user-guides/warehouse-data-share#step-2-add-the-destination) |
| How much High or Critical residual risk does each business unit carry? | [Read the heat grid](/user-guides/program-insights#step-4-read-the-heat-grid) |
| What did an AI agent do, and who approved it? | [Read the ledger](/user-guides/agent-ledger#step-1-read-the-ledger) |
| How do I triage a long tail of vendors cheaply? | [Zero Touch Assessment guide](/user-guides/zero-touch-assessments#running-one) |
| The Zero Touch run matched the wrong company. | [Reviewing a run](/user-guides/zero-touch-assessments#reviewing-a-run) |
| I set a finding to Mitigated and it went back to Finalizing response. | [How commitments set the finding status](/user-guides/findings-and-remediation#how-commitments-set-the-finding-status) |
| How do I ask a vendor to commit to a fix by a date? | [Requesting a commitment](/user-guides/findings-and-remediation#requesting-one) |
| I turned on obligation extraction and nothing appeared. | [Turning on automatic extraction](/user-guides/obligations#turning-on-automatic-extraction) |
| How do I get a business unit to confirm they operate a control? | [Asking a business unit to acknowledge](/user-guides/obligations#asking-a-business-unit-to-acknowledge) |
| Is this vendor a real registered company? | [Read the verdict first](/user-guides/corporate-registrations#read-the-verdict-before-the-identifiers) |
| The registry says dissolved. Now what? | [What to do with a dissolved status](/user-guides/corporate-registrations#what-to-do-with-a-dissolved-status) |
| Why does one vendor say "not screened"? | [No findings and not screened](/user-guides/people-intelligence#no-findings-and-not-screened) |
| Can I compare two financial health scores? | [The tier tells you what the number is worth](/user-guides/financial-health-score#the-tier-tells-you-what-the-number-is-worth) |
| A sanctions match came up. How do I clear it? | [Deciding](/user-guides/sanctions-screening#deciding) |
| Which sanctions lists do we screen against? | [Sanctions and watchlists](/user-guides/screening-coverage#sanctions-and-watchlists) |
| A source is collecting but no signals appear. | [Which vendors are watched](/user-guides/radar-signals#which-vendors-are-watched) |
| How do I stop a detector firing on routine patch notes? | [Testing before you enable](/user-guides/radar-signals#testing-before-you-enable) |
| How do I feed my Black Kite portfolio into Radar? | [Connect your credentials](/user-guides/black-kite-monitoring#step-1-connect-your-credentials) |
| Why is a Black Kite company not matching my vendor? | [Fixing a vendor that will not match](/user-guides/black-kite-monitoring#fixing-a-vendor-that-will-not-match) |
| How do I upload a vendor's SBOM? | [Uploading a bill of materials](/user-guides/bill-of-materials#uploading-a-bill-of-materials) |
| My SBOM says Unsupported. | [Supported formats](/user-guides/bill-of-materials#supported-formats) |
| Why did an SBOM raise no alerts? | [Which vulnerabilities are checked](/user-guides/bill-of-materials#which-vulnerabilities-are-checked) |
| Can we get an alert when a vendor files a breach notice? | [What Coverbase monitors](/user-guides/breach-notification-monitoring#what-coverbase-monitors) |
| Can we get an alert when an earthquake or flood hits a supplier's site? | [How a hazard reaches a vendor](/user-guides/natural-hazard-monitoring#how-a-hazard-reaches-a-vendor) |
| A treated risk still reads Outside appetite. | [Reading the register](/user-guides/risk-register#reading-the-register) |
| What does the risk agent do on its own? | [The agent](/user-guides/risk-register#the-agent) |
| Why is a supplier missing from the geography map? | [Archived suppliers](/user-guides/risk-geography-map#archived-suppliers) |
| Several suppliers share one address. Can I see them all? | [Many suppliers at one address](/user-guides/risk-geography-map#many-suppliers-at-one-address) |
| I forwarded an agreement to the inbox and nothing appeared. | [The inbox log](/user-guides/contracts-repository#the-inbox-log) |
| Which contract approval chain applies to a request? | [The approval chain](/user-guides/contract-intake-and-approval#the-approval-chain) |
| Where do I write acceptable and unacceptable clause language? | [Write your risk-tier variants](/user-guides/contract-guardian#step-4-write-your-risk-tier-variants) |
| I have my clause playbook in Excel already. | [Get the template](/user-guides/clause-set-spreadsheet-import#get-the-template) |
| Which packaged clause set should I start from? | [Choosing a starting point](/user-guides/clause-set-library#choosing-a-starting-point) |
| Can I build a clause set from my own MSA? | [Run an extraction](/user-guides/baseline-contract-extraction#run-an-extraction) |
| The vendor sent back a marked-up contract. What changed? | [See what changed](/user-guides/contract-negotiation-rounds#step-2-see-what-changed) |
| Should this insight use Extract or Synthesize? | [Extract vs Synthesize](/user-guides/document-insights#extract-vs-synthesize) |
| Can I ask a vendor's documents a question in chat? | [Asking your documents a question](/user-guides/document-evidence-pull#running-one) |
| Why can I not clear a contract date? | [Fixed dates versus calculated dates](/user-guides/contract-dates-and-reminders#fixed-dates-versus-calculated-dates) |
| Renewal reminders are going to the wrong people. | [Who gets reminded, and when](/user-guides/contract-dates-and-reminders#who-gets-reminded-and-when) |
| How do I stop reminders on one contract? | [Turning off a reminder for one contract](/user-guides/contract-dates-and-reminders#turning-off-a-reminder-for-one-contract) |
| When does a document expiry reminder go out, and to whom? | [Who receives it](/user-guides/document-expiry-reminders#who-receives-it) |
| A signer says the link does nothing. | [Common problems](/user-guides/signature-envelopes#common-problems) |
| Why will my signature template not let me edit it? | [Versioning: what freezes, and when](/user-guides/signature-templates#versioning-what-freezes-and-when) |
| Does a signer have to initial every page by hand? | [Adopting a signature](/user-guides/signature-signing-experience#adopting-a-signature) |
| How do I prove someone signed on a given date? | [The audit trail](/user-guides/signature-envelopes#the-audit-trail) |
| I sent an envelope to the wrong person. | [Nudging, correcting, canceling](/user-guides/signature-envelopes#nudging-correcting-cancelling) |
| A workflow fired but no run appears. | [Testing and enabling](/user-guides/building-a-workflow#testing-and-enabling) |
| A workflow step says Skipped. Why? | [Reading the runs page](/user-guides/building-a-workflow#reading-the-runs-page) |
| Which ready-made workflow should I turn on first? | [The nineteen templates](/user-guides/workflow-templates#the-nineteen-templates) |
| Who receives which Coverbase email? | [Who receives what](/user-guides/email-notifications#who-receives-what) |
| How do I put our logo on vendor emails? | [Applying your own branding](/user-guides/email-notifications#applying-your-own-branding) |
| How do I send vendor email from our own domain? | [Two ways to set it up](/user-guides/white-labeling#two-ways-to-set-it-up) |
| What does Coverbase ask a supplier in Germany for? | [Germany](/user-guides/supplier-countries/de) |
| Who approves a supplier's bank details? | [Review: the part that stops fraud](/user-guides/supplier-information#review-the-part-that-stops-fraud) |
| How does supplier data reach our ERP? | [Getting it into your finance system](/user-guides/supplier-information#getting-it-into-your-finance-system) |
| Can I run an RFP without emailing every vendor? | [Run it without outreach](/user-guides/running-an-rfp#part-3-run-it-without-outreach) |
| An inspection finished. Did anything pass? | [Reading an inspection](/user-guides/internal-controls-monitoring#reading-an-inspection) |
| How do I check one setting every hour? | [Probes](/user-guides/internal-controls-monitoring#probes) |
| Which report format should I hand to an examiner? | [Which one to use](/reporting/overview#which-one-to-use) |
## Need a hand
<CardGroup>
<Card title="Product support" icon="envelope" href="mailto:support@coverbase.ai">
Email [support@coverbase.ai](mailto:support@coverbase.ai) for technical questions.
</Card>
<Card title="Live working sessions" icon="chalkboard-user">
Your Coverbase team runs hands-on sessions and walks through each step on screen with you.
</Card>
</CardGroup>
<Note>
The screenshots throughout these guides come from a demo environment with sample vendors and data. Your environment will show your own vendors, branding and configuration.
</Note>
# People intelligence guide
Source: https://docs.coverbase.com/user-guides/people-intelligence
How to read the leadership dossier on a vendor, what confirmed and unconfirmed mean, and how to treat an adverse-media finding.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For what the capability is and where it stops, see [People intelligence](/products/people-intelligence).
</Info>
Corporate registrations tell you the company is real. This page tells you who runs it, and what public sources say about them.
It runs on its own once a vendor has a website on file.
## Finding it
Open a vendor, go to **Vendor Intelligence**, and pick the **People** tab.
<Frame>
<img alt="The People tab for a vendor, showing a screening result of one adverse finding, a Who we could confirm ladder by role, three adverse-media findings, four confirmed people and one unconfirmed name, and a collapsed drawer of reporting lines and citations." />
</Frame>
## Confirmed and unconfirmed
Read this distinction before you read anything else on the page.
Searching a person's name returns other people with that name, and a better-known one will dominate the results. So every name lands in one of two groups, and only one of them counts.
**Confirmed** people were tied to this vendor by a source that resolved through the vendor's own domain, or by a matched professional profile. They are the only names counted under **Who we could confirm**, drawn in the reporting tree, or fed into a score.
**Unconfirmed** names were surfaced in research but could not be tied to this vendor with confidence. They appear at the end of **Who we found**, marked **Unconfirmed**, and in no coverage count or score.
<Warning>
Do not quote an unconfirmed name as the vendor's staff. It is a research lead. The section exists so you can judge it yourself rather than have it dropped silently.
</Warning>
## Reading a finding
Every adverse-media finding carries three labels, and they answer different questions.
| Label | Question it answers |
| - | - |
| Severity | How serious is the matter? |
| Category | What kind of matter is it? Litigation, regulatory, financial crime, sanctions, insolvency, conduct. |
| Outcome | Where did it get to? Alleged, under investigation, settled, concluded, dismissed, or unclear. |
Severity and outcome together are what you act on. A high-severity litigation finding marked **Dismissed** is a claim the subject won, and it deducts nothing from the Zero Touch score. A high-severity finding marked **Concluded** is a different matter.
Findings the subject publicly contests are labeled disputed, so you are never handed one side of a contested matter as settled.
<Note>
A sanctions match is always shown at high severity, and always with the caveat that name similarity is not identity. Open the listing and confirm before you act on one.
</Note>
## Who was screened
Screening is bounded. Founders and executives are screened first, then the board, then other leadership.
Each person's row in **Who we found** says **Screened** or **Not screened**. The screening result at the top says how many people were screened. On a large leadership team, names at the end of the list may not have been screened, so check where the line fell.
## No findings and not screened
When screening could not run at all, the page says so and shows no count.
<Frame>
<img alt="The People tab with adverse-media screening not run, showing an explanatory notice in place of a findings count." />
</Frame>
<Warning>
A zero looks like a clean record, but "not screened" and "no findings" mean different things. If you are about to write "no adverse findings" into an assessment, check first whether the vendor was screened at all.
</Warning>
## Other labels worth knowing
**Named officer** means the person appears as an officer or director in a public filing. That is a stronger claim than a name taken from a leadership page.
**Politically exposed** means the person holds or held prominent public office, or is close to someone who does. It calls for enhanced diligence. It is not a finding against them.
**Also on the board of** lists other organizations where the person holds a seat. The same names recurring across a vendor's board and its counterparties is worth a question. The page shows the seats; it does not judge them.
## Troubleshooting
| Symptom | Fix |
| - | - |
| No leadership on record | The vendor has no website on file, or publishes nobody. Add a website if it is missing. A private company that names nobody is telling you about its disclosure, not its risk. |
| The same person appears twice | A nickname and a legal first name are kept as separate records. A visible duplicate is safer than a wrongly merged pair. Treat them as one person. |
| A finding is about someone else | Open the actions menu (**...**) at the top of the page and pick **Correct the AI**. Describe the problem under **What should the model know?**, choose **This is a different company** and give the right website if the research bound the wrong company. The tab is researched again straight away. |
| Reporting lines look incomplete | They are reconstructed from published relationships. Nobody publishes a full org chart. |
## Related
<CardGroup>
<Card title="Corporate registrations guide" icon="building-columns" href="/user-guides/corporate-registrations">
The legal entity behind the people.
</Card>
<Card title="Zero Touch Assessments" icon="bolt" href="/user-guides/zero-touch-assessments">
Leadership and adverse media as a scored component.
</Card>
</CardGroup>
# Permissions and roles
Source: https://docs.coverbase.com/user-guides/permissions-and-roles
How access works in Coverbase: the six default roles, how a permission is built from a resource, an action and a scope, and how to build and assign a custom role.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is for admins who decide who can see and change what. If you are setting up a new environment, do this after [Admin and setup](/user-guides/admin-setup) step 1, once your team is invited.
</Info>
A role answers two questions for every person in your organization: what they can see, and what they can change. Coverbase ships six roles that cover most teams. When none of them fits, you build a custom role by turning individual permissions on and off.
<Info>
Custom roles are a gated feature. **Configuration → Organization → Roles** always shows what each role can do, but if it shows a read-only table instead of the editor described below, custom roles have not been switched on for your organization yet, or your own role cannot edit organization settings. Ask your Coverbase contact. The six default roles work either way.
</Info>
## The six default roles
Every member holds exactly one role. These six ship with the product and cannot be edited, but you can clone any of them as a starting point.
| Role | Who it is for | What they can do |
| - | - | - |
| **Admin** | Program owners | Everything, including members, roles, integrations, API keys, and organization settings |
| **Member** | Your core risk and procurement team | Create and edit vendors, assessments, findings, follow-ups, intake requests, RFPs, tags and comments across the organization. Read controls and monitoring, and triage Radar alerts. Cannot manage members, roles, integrations, custom fields, monitoring rules, or settings |
| **Siloed Member** | Analysts who should only see their own book of work | The same as a Member, except vendors, services, contracts, assessments, findings, commitments and follow-ups are limited to records they own, watch, or analyze. Intake, portals, tags, questionnaires and comments stay organization-wide. Can read RFPs and score their submissions, but not change or award them |
| **Auxiliary Member** | Collaborators outside the core team | Answer inherent-risk questionnaires, complete tasks assigned to them, and comment on records they are assigned to |
| **Guest** | External collaborators | Read-only access across the organization, plus what an Auxiliary Member can do: answer inherent-risk questionnaires, complete assigned tasks, and comment on assigned records |
| **Service Account** | Integrations, not people | Everything the public API exposes: vendors, assessments, findings, contracts, questionnaires, obligations, monitoring, custom fields, webhooks, workflows and supplier records. Cannot approve anything, and cannot reach roles, API keys, billing, organization settings, or the audit trail |
Start with **Member** for anyone on the risk team and **Admin** for the one or two people who own the program. Reach for a custom role only when a real job does not fit.
<Note>
**Service Account is the role your API keys use.** Every key your organization issues authenticates as it, so editing that role changes what your integrations can do. One rule to know: a service account can *request* a change to supplier bank details but cannot approve one. Approving stays with a person.
</Note>
<Tip>
Understand **Siloed Member** before you assign it. It does not hide a smaller list of features. It shows the same features against a smaller set of records: the vendors and assessments that person owns, watches, or analyzes. If someone says a vendor "disappeared", check whether they are a Siloed Member who was removed as an owner.
</Tip>
## How a permission is built
Every permission in Coverbase is three things joined together.
<CardGroup>
<Card title="Resource" icon="cube">
The thing being acted on. Vendors, assessments, findings, contracts, controls, API keys and the rest, grouped in the editor into **Vendor risk**, **Controls and detection**, **Workflow and intake**, and **Administration**.
</Card>
<Card title="Action" icon="bolt">
What you are doing to it: read, create, update, export, assign, approve, comment, archive, or run.
</Card>
<Card title="Scope" icon="crosshairs">
How much it covers: every record in the organization, or only the records that person is assigned to.
</Card>
</CardGroup>
"A Member can update any vendor in the organization" is the resource `vendor`, the action `update`, and the scope `all records`. "A Siloed Member can update the vendors they own" is the same resource and action at a narrower scope.
Not every combination exists. Some resources have no per-record assignment, so scope does not apply to them: there is no such thing as being assigned to an API key or to organization settings. Those are always organization-wide, and the editor shows them that way.
## Finding the role editor
Go to **Configuration → Organization → Roles**. The **Roles** list on the left shows every role in your organization and how many permissions it holds, with a **Default role** badge on the six that ship with the product. Selecting one opens it on three tabs: **Permissions** (the matrix), **Members**, and **Activity**.
Default roles are read-only. To base a new role on one, open it and choose **Clone**. A custom role you no longer need can be archived with **Archive**; tick **Show archived** under the list to see archived roles again.
## Reading the permission matrix
The matrix has one row per resource and one column per action, and the legend above it names each value. Each cell holds one of four values.
| Cell | Legend | Means |
| - | - | - |
| **O** | **Org-wide** | Every record of that type in the organization |
| **A** | **Assigned only** | Only the records that person is assigned to or watches |
| **·** | **Off** | No access for that action |
| **–** | **Not applicable** | That resource does not support that action |
A cell with a red **!** is a **Conflict with hierarchy**: a combination the rules below do not allow.
Resources sit in four collapsible groups, each showing how many of its permissions are granted. **Set all** on a group switches every cell in it to **Off**, **Assigned** or **Org** at once.
Click a cell to cycle it through off, assigned only, and org-wide. Right-click to pick **No access**, **Assigned only** or **All records** directly. Use **Filter by resource or action** to narrow a large matrix while you work, and **Show** to switch between **All** rows, only the **Granted** ones, and only your unsaved **Changes**.
Assigned scope is not available everywhere. A resource with no assignment model only offers all records or no access, and the cell says so when you hover it.
## The rules the editor enforces
Some combinations describe a role the product cannot deliver. The editor catches those before you save, shows them in a banner above the matrix, and offers **Fix all**.
<AccordionGroup>
<Accordion title="An action needs the matching read" icon="eye">
You cannot give someone update, approve, assign, archive, export, comment or run on a resource without also giving them read at the same scope. Editing a record you cannot open is not a narrower permission, it is a broken screen.
The fix is to raise read to the scope the other action needs.
</Accordion>
<Accordion title="Vendor-backed resources need vendor read" icon="link">
Assessments, findings, commitments, services and Radar alerts are all reached through a vendor. Granting one of them without vendor read produces a page the person cannot open. The editor requires vendor read alongside any of these.
</Accordion>
<Accordion title="Create without read is a warning, not an error" icon="triangle-exclamation">
A role that can create records but not read them is unusual, and the banner says so, but it saves. It is a real pattern for an intake submitter or a write-only integration that files records it never lists.
</Accordion>
<Accordion title="You cannot grant what you do not hold" icon="shield-halved">
If your own role does not include a permission, you cannot give it to another role. Admins hold everything, so this never limits them. It matters when you delegate role management to someone who is not an Admin: they can build roles up to their own level of access, and no further.
To create a role broader than your own, ask an Admin to do it.
</Accordion>
<Accordion title="You cannot lock yourself out" icon="key">
Editing the role you yourself hold, you cannot remove its ability to read and manage roles. Doing so would leave you unable to reopen the editor and undo it. Another Admin can still change your role for you.
</Accordion>
</AccordionGroup>
## Building a custom role
<Steps>
<Step title="Start from the closest default">
Open the default role nearest to what you want and choose **Clone**, or choose **+** beside **Roles** (**New role**) to start from nothing. Cloning is usually faster, and it starts you from a set that already passes the rules above.
</Step>
<Step title="Name it for the job, not the person">
"Contract reviewer" outlasts "Priya's role". Names show up in the member list and in the audit trail.
</Step>
<Step title="Set the matrix">
Work resource by resource. For each one, decide read scope first, then the actions on top of it. Filtering by resource keeps you out of the rest of the matrix while you do it.
</Step>
<Step title="Clear the banner">
Fix anything the validation banner reports. **Fix all** resolves each issue in the direction you were heading: where the resource still has some read access, it raises read to the scope the other permission needs; where read is off entirely, it removes the permission that depended on it.
</Step>
<Step title="Save, then add members">
A new role's first save is **Create role**; after that the button reads **Save** with a count of your changes. Members can only be added to a saved role, so save first, then use the **Members** tab.
</Step>
</Steps>
## Assigning people to a role
The **Members** tab on a role shows everyone who holds it. Add someone with **Add to role**, and remove them with **Remove from role**. You can also change a person's role from the **Role** column on **Configuration → Organization → Members** (**People** on the redesigned settings).
Two things are blocked:
* **The last Admin cannot be demoted or removed.** Make someone else an Admin first. This applies whether you are removing them from the Admin role or assigning them a different one.
* **Changing your own role asks for confirmation.** If the change removes your own administrative access, you lose it immediately, and only another Admin can give it back.
Members always hold a role. To move someone out of a role, add them to a different one rather than removing them from their current one.
## What custom roles do not restrict
A few areas are visible and actionable for every member regardless of role. They are listed in the editor under **Not restricted by custom roles** so you are not left looking for a toggle that does not exist.
| Area | Behavior |
| - | - |
| Inspect | Visible to all users |
| Risk | Visible to all users |
| RFP | Visible to all users |
| Procurement | Visible to all users |
| Vendor performance management | Visible to all users |
| Reports and dashboards | Data visible to all users. Editing is Admin-only |
Some surfaces have no toggles of their own because they follow the records they act on. Email, engagements, Coverbase AI and Radar signals inherit the permissions of whatever they are acting on.
Configuration pages follow the permission for the thing they configure. Clause sets follow contract permissions. The risk scale and Document Insights settings follow organization settings.
## Seeing what changed
Every role carries its own activity log, on its **Activity** tab. It records who changed the role and what they changed, so a permission that appeared or disappeared can be traced to a person and a time. A newly created role has no activity until it is saved.
Role changes also appear in the organization-wide audit trail alongside everything else. See [Audit trails](/security/audit-trails).
## Troubleshooting
| What you are seeing | What is happening |
| - | - |
| Someone cannot see a vendor they expect to | They are probably a Siloed Member and are not an owner, watcher, or analyst on it. Add them to the vendor, or move them to Member |
| A permission will not turn on | Check the banner. It is likely missing the read it depends on, or vendor read for a vendor-backed resource |
| You cannot grant a permission you can see | Your own role does not hold it. An Admin can grant it |
| A cell shows **–** (**Not applicable**) | That resource does not support that action. Nothing is wrong |
| A cell will not go to **Assigned only** | That resource has no per-record assignment, so it is all records or nothing |
| **Roles** shows a read-only table instead of the editor | Custom roles are not switched on for your organization, or your role cannot edit organization settings. Ask an Admin or your Coverbase contact |
| You cannot remove the last Admin | Intended. Promote someone else first |
## Related
<CardGroup>
<Card title="Admin and setup" icon="sliders" href="/user-guides/admin-setup">
The full setup sequence. Roles come after inviting your team.
</Card>
<Card title="Audit trails" icon="clipboard-list" href="/security/audit-trails">
Every recorded event, including role and membership changes.
</Card>
<Card title="API keys" icon="key" href="/api-reference/api-keys">
Service accounts and scoped keys for integrations.
</Card>
<Card title="MCP permissions" icon="robot" href="/mcp/permissions">
How the same permissions apply when an AI assistant acts on your data.
</Card>
</CardGroup>
# Program Insights
Source: https://docs.coverbase.com/user-guides/program-insights
Read Program Overview: choose a level, apply slicers, read the five KPIs, the residual heat grid and the pre-contract pipeline, open the list behind any figure, export the view, and generate the board pack.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Program Overview**, under **Dashboards** in the left navigation. It sits beside [Dashboards and the chart library](/user-guides/dashboard-library) and [Warehouse data share](/user-guides/warehouse-data-share). For what the page is, see [Program Insights](/products/program-insights).
</Info>
Program Overview is a single page for the state of your third-party risk program. You choose how to count (the level), narrow it with slicers, and open the list behind any figure.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
The mistake people make most often is comparing figures taken at different levels. The **Enterprise** level counts each third party at its worst domain score across its engagements, so it reads higher than the **Third party** level for the same portfolio. Name the level when you quote a number.
## Step 1: Open the page
Open **Dashboards** in the left navigation and choose **Program Overview**. Seeing it needs permission to view dashboards.
<Frame>
<img alt="Program Overview with Level set to Enterprise, six slicers, five KPI tiles, a residual heat grid by business unit and domain, and the pre-contract pipeline" />
</Frame>
## Step 2: Choose a level and slicers
Under **Level**, choose **Enterprise**, **Engagement** or **Third party**. The description under it says how rows are scored.
Then narrow the view with the slicers: **Tier**, **Business unit**, **Contract type**, **Control status**, **Geography** and **Risk domain**. Each one opens a searchable list. **Geography** lists regions (such as **EU**, **North America** and **Latin America**) above single countries; a region matches a third party with an active site in any of its countries. **Clear** removes every slicer at once.
Business units appear in your organization's order everywhere, on the grid and in the slicer. To change it, go to **Settings** > **Contract Setup Lists** and click **Reorder** next to business units; drag a unit, or use the arrow buttons or keyboard, then save. Units not yet placed follow, by name.
The level and slicers are kept in the page's address, so copying the link shares exactly this view.
## Step 3: Read the KPIs
| KPI | What it counts |
| - | - |
| **Active Engagements** | Live engagements, less those the Transaction Owner decided not to proceed with and those whose exit completed, and how many third parties they span. An engagement with an exit under way still counts until its exit completes. |
| **High or Critical Residual** (named after your elevated levels) | Rows whose residual level is one of the top two levels of your default risk scale (the top one on a scale of three or fewer), out of those scored, with the change since the start of the quarter (UTC). With a **Risk domain** slicer, a row counts when any selected domain is elevated. |
| **Reviews Past SLA** | Open domain reviews past their SLA, out of those in flight. |
| **Issues Past Due** | Open findings past their due date on third parties in scope, and how many engagements at Decision or Contract they block. |
| **Request to Decision** | The median days from the request (the engagement's creation, or an earlier intake for a linked assessment) to the Transaction Owner's decision, over decisions in the last 90 days. |
Click a KPI to open the list it counts.
## Step 4: Read the heat grid
**Residual Risk · Business Unit × Domain** shows the mean residual score (0 to 100) for each business unit and risk domain, coloured by the risk level it falls in. Engagements decided not to proceed, and engagements whose exit completed, are left out. Hover a cell for its mean, its risk level, how many were scored and how many sit at the elevated levels. Click a cell to open the list. **No business unit** collects records that have none.
### Drill into a business unit or an engagement
Click a business unit to narrow every figure on the page to it; the grid then lists its third parties or engagements as rows, worst first (the first 50, with the total). Click an engagement to see it on its own: it is counted at the engagement level whatever the level switch says, and only the **Risk domain** slicer still applies. **Back to the business unit** and **Back to all business units** step back out. The drill is part of the link too.
## Step 5: Read the pipeline
**Pre-contract Pipeline · Engagements by Stage** counts open intake requests (submitted or in review, not yet decided) at **Request**, then live engagements at **Triage**, **Inherent risk**, **Due diligence**, **Decision** and **Contract**. Click a bar to open those engagements.
An engagement that is active, exiting or exited is past the pipeline and has no bar. When you drill into one, a line under the bars says so: an exiting engagement still counts as active until the exit completes, and an exited one is out of the program's figures.
<Frame>
<img alt="Pre-contract Pipeline card with every stage at zero and the note: This engagement is exiting, so it is past the pipeline. It still counts as active until the exit completes." />
</Frame>
## Step 6: Export and distribute
* **Export** saves the view as **Excel (.xlsx)** or **CSV**, with the level, the time it was generated, the KPIs, the heat grid and the pipeline.
* **Generate board pack** builds the board pack and downloads it when it is ready.
* The **Distribution** card lists where the program's data goes: each warehouse destination with its last sync, the Power BI feed (the Snowflake destination it reads, with its health), the board pack schedule, scheduled dashboard emails, and a link to your own open tasks. **Manage** opens [Data Share](/user-guides/warehouse-data-share).
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **Program Overview** under **Dashboards** | The third-party lifecycle features are not turned on for your organization, or your role cannot view dashboards. | Ask your Coverbase representative, or an admin. |
| An offboarded engagement is missing from the figures | Its exit completed. | Expected. Exited engagements leave the program's figures. |
| **No residual scores yet** | No assessment has set residual risk by domain. | Complete assessments with domain residual scores. |
| **Nothing scored matches these slicers.** | The slicers exclude everything. | **Clear slicers**. |
| The opened list shows more rows than the figure | Most drills filter the list exactly. Enterprise level risk figures, the elevated KPI with a risk domain slicer, and issues at the engagement level name up to 100 matching rows instead, so a larger set cannot be listed exactly. | Expected. The page warns before you open it. |
| **Couldn't refresh this view.** | The latest figures failed to load. The page keeps the last view that loaded. | Click **Retry**. |
## Related
<CardGroup>
<Card title="Dashboards and the chart library" icon="chart-line" href="/user-guides/dashboard-library">
Your own dashboards.
</Card>
<Card title="The engagement record" icon="route" href="/user-guides/engagement-record">
The stages the pipeline counts.
</Card>
<Card title="Warehouse data share" icon="database" href="/user-guides/warehouse-data-share">
The destinations on the Distribution card.
</Card>
<Card title="Program Insights" icon="chart-pie" href="/products/program-insights">
What the page is.
</Card>
</CardGroup>
# Questionnaires
Source: https://docs.coverbase.com/user-guides/questionnaires
Build a questionnaire template, decide who reviews it, send it to a vendor, and work a submission through to a decision. Covers question types, conditional logic, internal-only questions, write-back rules, and why editing a template does not change answers already given.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Questionnaires** area under **Configuration**. For the packaged inherent risk templates, see [The IRQ library](/user-guides/irq-library). For weighting an IRQ during setup, see [Step 4 of Admin setup](/user-guides/admin-setup#step-4-build-and-weight-your-irq). For follow-up questionnaires raised from an assessment, see [Running an assessment](/user-guides/running-an-assessment).
</Info>
A questionnaire is a template you build once and send many times. Each send creates a submission: one vendor, one set of answers, one status, one reviewer. The template and the submission are different records, and that split explains most of what follows. Editing the template changes what the next vendor sees. It never rewrites what an earlier vendor answered.
The mistake people make most often is on the reviewer side. Adding someone under **Configure Reviewers** puts them on a notification list. It does not put the submission in their work queue. The reviewer picker on the submission itself does that.
## Where questionnaires live
Open **Configuration** and choose **Questionnaires**, or go straight to `/questionnaires`. The page opens on the **Inherent Risk** tab. Each tab is one questionnaire type, with the templates of that type listed down the left and the selected template on the right.
| Tab | Type | Used for |
| - | - | - |
| **Inherent Risk** | `irq` | Scoring a vendor before due diligence. Answered at intake, or sent from the vendor page. Produces an inherent risk score. |
| **Assessment** | `assessment` | Questions collected as part of an assessment plan. Can be built by hand or derived from a control set. |
| **Informational** | `informational` | Anything you want to ask a vendor that does not score: a data map, a contacts form, a renewal check. Sent directly from the template. |
| **Know-Your-Vendor** | `vendor_onboarding` | Supplier profile collection (bank accounts, sites, tax registrations). Only shown when the module is on. See [Supplier information](/user-guides/supplier-information). |
| **Performance** | `performance` | Performance review questionnaires. |
| **RFP Pre-qualification**, **RFP Response** | `rfp_prequalification`, `rfp_response` | Only shown when the RFP module is on. See [Running an RFP](/user-guides/running-an-rfp). |
Follow-up questionnaires (`follow_up`) have no tab. They are generated from assessment issues, and you reach their submissions from the assessment. Their template page only lists the submissions made on them.
<Frame>
<img alt="The Questionnaires page with the Inherent Risk tab selected and a template open on the Template tab" />
</Frame>
## Creating a template
Click **Create Questionnaire** above the list. The new template opens with no questions. On the **Inherent Risk** tab you can instead click **IRQ Library** and copy a packaged template. On the **Assessment** tab the button is a menu: **Create Assessment Questionnaire**, or **Create Questionnaire from Control Set**, which derives a questionnaire from a control set of type policy or questionnaire. On the **Know-Your-Vendor** tab the menu also offers **Use default Know-Your-Vendor Template**.
<Note>
A derived questionnaire is owned by its control set. A blue banner at the top says which one, with **Go to control set**. You cannot edit its questions, reviewers, or comment settings here; change the control set and the questionnaire follows. Controls that are not questions are filtered out, and an orange banner tells you when that has happened.
</Note>
Creating a template needs the `questionnaire:create` permission. Editing one needs `questionnaire:update`, and deleting needs `questionnaire:archive`. See [Permissions and roles](/user-guides/permissions-and-roles).
## Building the template
The **Template** tab is an editor with a **Save** and **Cancel** bar. Nothing reaches the server until you click **Save**, and most of the **Actions** menu is disabled while you have unsaved changes. If someone else saves the same template while you are editing, a **Questionnaire changed** dialog asks you to **Reload now**; your local edits are discarded.
### Title, sections, and order
The fields at the top are **Questionnaire title** and **Questionnaire description**. Both are shown to the respondent.
Click **New Section** to add a section. A section has a **Section Name**, an optional description, a **Section Index**, and a **Risk Domain**. The risk domain matters on an IRQ: it decides which domain a section's questions score into, and it is what [domain weighting](/user-guides/irq-library#weighting-risk-domains) and per-domain review are keyed on. Drag sections and questions to reorder them. **Actions → Number Questions** fills in a question index for every question, either **Sequential (1, 2, 3)** or **By section (1.1, 1.2, 2.1)**, and can leave questions that already have an index alone.
### Adding a question
Click **Add** and choose a response type. When the template has sections, the menu asks which section first.
| Response type | The respondent gives | Notes |
| - | - | - |
| **Single Select** | One option | Can score, can trigger conditional logic, can drive fixed write-back rules. |
| **Multi Select** | Several options | Same as single select. Scoring mode is **Cumulative** (sum of selected values) or **Highest score** (the top selected value). |
| **Text** | Free text | Cannot trigger conditions. Write-back copies the answer into a field or asks AI. |
| **Contacts** | One or more people | Write-back can copy the people it names into a user custom field. |
| **Country** | One country, or several | Choose **One country** or **Several countries** in the question's settings. Can trigger conditions, and write-back can add each country as a location. |
| **Currency** | An amount | |
| **Document Upload** | A file | Know-Your-Vendor only. |
| **Bank Account**, **Site / Address**, **Tax Registration**, **Diversity Record** | A supplier profile record | Know-Your-Vendor only, except that an inherent risk questionnaire can also ask **Site / Address** when the Know-Your-Vendor module is on. The answer is a reference to the vendor's profile, not a copy of the values. |
Every question has a **Question title** and optional **Additional instructions**. Select questions have options, each with a **Value**: the weight that feeds the score. Options start at `0`, so weight them before the first send. An option's **Score override** sets a **Minimum score override**: when that option is selected, the questionnaire's overall score cannot fall below the percentage you enter, and the highest override among the selected answers wins.
<Frame>
<img alt="An expanded question in the template editor showing General Settings and the options list with values" />
</Frame>
### Question settings
Open a question's settings to find these switches. Select several questions and use the bulk actions bar to set **Required question** and the comment and attachment switches at once.
| Setting | What it does |
| - | - |
| **Required question** | The respondent cannot submit until it is answered. On an internal-only question the label changes to **Required before accepting or denying**, because it gates the reviewer instead. |
| **Internal only** | Hidden from whoever fills in the questionnaire. Autofill still answers it, and your team sees it when reviewing the submission. |
| **Allow comments** / **Require comment** | Adds a comment box. Required means the vendor must explain their answer before the question counts as answered. |
| **Allow respondents to add their own** | Select questions, when your organization uses the [centralized supplier portal](/user-guides/centralized-supplier-portal). The respondent can answer with a value you did not list. A custom answer scores nothing and satisfies no conditional logic. |
| **Allow document attachments** / **Require document attachments** | Lets or makes the respondent attach supporting documents to this question. |
| **Require user review** | Intake only. The requester must confirm the AI answer to this question. |
| **Require user input** | Intake only. The question is always put to the requester as a follow-up rather than answered from web search. Use it for facts only the business owner knows. |
**Update AI Guidance** under the question's **Actions** adds instructions for how the AI should answer this question during intake. **Copy Question ID** is there for workflow automations that reference a question.
### Internal-only questions
An internal-only question is a fact your team wants recorded about the vendor without asking the vendor. The portal strips the question and any answer to it. Autofill answers it like any other question, and the reviewer sees it, with its answer and the model's reasoning, on the submission. Marked **Required**, it blocks both **Accept** and **Deny** until someone answers it; the buttons show how many are outstanding.
Two things to know before you use one:
* It scores like any other question. Leave option values at `0` on a question that is context rather than risk.
* It can only show other internal-only questions through conditional logic. A respondent-facing question can show an internal-only one (the vendor answers, the rule decides whether your reviewer is asked the follow-up), but not the other way round, because the vendor would be blocked on a question they cannot see.
Turning **Internal only** off on a question your reviewer has already answered exposes that answer to the vendor if the portal is reopened.
### Conditional logic
**Actions → Configure Conditional Logic** opens the rule list for the template. A rule shows one or more sections, questions, or options when a trigger question's answer matches. Anything a rule targets is hidden until a rule for it fires, and the rules for one target read **when ANY of these rules is met**, so two rules on the same section are an OR.
Inside a rule, each condition is a trigger question plus **is any of** or **is not any of** and the options it compares against. A rule can combine up to ten questions, all of which must be true (**when ALL of the following are true**), and each must be a different question. Only single select, multi select, country, and currency questions can be triggers, and a question cannot show the section it sits in. An unanswered trigger counts as not met, never as skipped.
<Frame>
<img alt="The Configure Conditional Logic dialog listing rules grouped by target section" />
</Frame>
A single **Add Conditional Logic** action also sits on each question, prefilled with that question as the trigger. Rules are saved immediately, so the action is disabled while the template has unsaved changes.
On the submission, a section or question a rule hid is listed under **Skipped because conditions were not met**, with the answer that was given against the answer the rule needed.
#### Importing rules from a spreadsheet
The top of **Configure Conditional Logic** takes an Excel file of rules, so a long questionnaire's logic does not have to be built one rule at a time. **Template** downloads an empty workbook. **Current rules** downloads the rules the template already has, in the same layout, so you can edit them and upload the file again. Both workbooks have two sheets. You write rules on **Conditional Logic**, one condition per row. **Questions** lists every question on the template with the ID to use for it, its type, its option labels, and its section. The import reads only the first sheet.
* **Rule**: optional. Rows with the same Rule make one rule, and all of their conditions must be met. Leave it blank for a rule with one condition. **Current rules** fills in the ID of each rule; keep it, and uploading the row updates that rule instead of adding a new one.
* **Parent Question ID**: the trigger question for the condition. Use the ID shown beside it in the editor (for example `1.1`) or the ID **Copy Question ID** gives you.
* **Predicate**: `one_of` (the default) or `not_one_of`, which the editor shows as **is any of** and **is not any of**.
* **Reference Values**: option labels from the trigger question, separated by `|`. Case and extra spaces are ignored. For a country or currency question, use ISO codes such as `US|CA`.
* **Target Question IDs**: the questions the rule shows, separated by `|`.
* **Target Section Names**: the sections the rule shows, by name, separated by `|`.
* **Target Options**: the options the rule shows, each written as the question's ID, a colon, and the option label (for example `1.2: Yes`), separated by `|`.
A rule shows one kind of target: questions, sections, or options. Its targets can sit on any of its rows; **Current rules** puts them on the first. A rule can combine up to ten conditions, each on a different question.
Every upload is previewed first. The preview counts the rows a confirm will create, counts a row whose rule already exists or that updates a rule as an update, and lists each row that will not import with the reason. A rule imports whole or not at all, so a problem on one of its rows holds back the others, which name the row to fix. **Download workbook with problems marked** gives you back your file with those reasons in a new column, ready to fix and drop in again.
An import adds and updates rules but never deletes one; delete a rule in the dialog. If someone changes or deletes a rule after you download **Current rules**, the rows carrying its old ID will not import. Download the current rules again, or clear the Rule cell to add the rule as a new one. The editor's checks apply to every rule: it cannot show one of its own trigger questions, a section that holds one, or options of one, and an internal-only question can only show other internal-only questions. The import also refuses a rule that would make a loop, where the rule shows a question that already decides, directly or through other rules, whether its trigger question shows. A respondent could never answer either one.
### Write-back: answers that update the record
**Configure write-back** on a question makes its answer write a value onto the vendor, onto its services, or, for an assessment questionnaire, onto the assessment. The panel asks for:
| Field | Choices |
| - | - |
| **Record** | **Vendor**, **Service**, or **Assessment**. **Service** is offered on every type except assessment questionnaires, and writes to every service on the intake (including ones created on acceptance) or to the services the questionnaire was sent for. **Assessment** is offered only on assessment questionnaires. |
| **Target** | **Tags**, **Custom field**, **Record field** (a built-in column such as description or website), or, on a country question, **Locations**: each country in the answer becomes a location on the record, and a country the record already lists is left alone. An assessment takes custom fields only. |
| **How** | **Fixed rules** for select questions: one rule per answer, each setting a tag or a literal value. **Copy the answer** for text and contacts questions: the answer is written as given into a text, number, or user custom field, or a text answer into a record field. **Ask AI** for any question: an instruction the model follows, and its reason is recorded. Country and currency answers use it for every target except **Locations**. |
| **Review before applying** | On by default. The reviewer confirms the suggestion on the submission. Off, it is applied on approval and still shown in the review panel. |
| **Prefill this answer from the record** | Vendor custom fields and record fields only. Answers the question from the value already on the record when the questionnaire is sent, so the vendor is not asked for something you already hold. An answer already given is never replaced. |
A question that asks for the vendor's own name fills itself in, with no write-back to configure. When the questionnaire is sent, Coverbase reads each unanswered text question's wording and fills in the name it asks for:
| The question asks for | Filled with |
| - | - |
| The legal, registered, company or supplier name | The legal name a reviewer confirmed for the vendor. Without one, the registered name the company registry lookup matched to the vendor. Without that, the vendor's name. |
| A trading name or "doing business as" name | The name you hold the vendor under, but only when it is more than the legal name without its "Inc." or "Ltd". Otherwise the answer stays blank. |
| The name in the local language or script | The vendor's local legal name, when one is on file. |
A question about someone else's name, such as a contact, a representative, a bank or a parent company, is left alone. So is any question already answered. The vendor sees the name filled in and can change it.
Three rules hold regardless of the settings. A write that would overwrite a value someone typed always asks. A built-in column is only ever filled when it is empty. Nothing lands on the record until the submission is approved.
<Frame>
<img alt="The Write back from this answer panel showing Record, Target, How, and Rules by answer" />
</Frame>
The custom field's own settings page lists every question that fills it under **Autofill from questionnaires**, so you can find a mapping from either end. See [Data model configuration](/user-guides/data-model-configuration).
<Note>
An older question may open **Configure Response Mapping** instead. That is the previous editor, and it stays only while the question still carries a mapping from it. Clearing that mapping switches the question to the write-back panel, and no new response mapping can be created.
</Note>
### Spreadsheet import and export
**Actions → Bulk Import Questions** opens a dialog that takes an Excel file. **Download blank template** gives you the column layout with example rows; **Download current questions** exports what is already on the template so you can edit and re-import it. The columns cover question text, type, required, pipe-separated options and weights, instructions, guidance, the comment and document switches, internal only, section name and order. Rows that fail come back in a **Download Errors** sheet with an **Error** column. Conditional logic has an import of its own, covered in [Importing rules from a spreadsheet](#importing-rules-from-a-spreadsheet).
**Actions → Export → Export Template as XLSX** downloads the template. **Export Submissions as XLSX** appears once the template has submissions and downloads every answer on the current page of the submissions table. A single submission has its own **Export as XLSX** in its actions menu.
### Other template actions
| Action | What it does |
| - | - |
| **Configure Reviewers** | The template's notification list. See [Assigning reviewers](#assigning-reviewers). |
| **Configure Risk Levels...** | IRQ only. Opens the inherent risk scale that the score is banded against. |
| **Intake Configuration** | IRQ only. Opens the vendor intake settings that decide which IRQ requesters answer. |
| **Configure Automation** | Informational only. Automatically selects this questionnaire when an assessment is created for vendors at the chosen inherent risk levels, or **Apply to all vendors**. |
| **Clone Template** | Copies the template under a new name. Not available for derived or RFP templates. |
| **Delete Template** | Archives the template. Its submissions stay on the vendor's history, but nothing new can be sent from it. |
## Assigning reviewers
Two different things are called the reviewer. Keep them apart.
<CardGroup>
<Card title="Template reviewers" icon="users">
Set from **Actions → Configure Reviewers** on the template. Everyone on the list is notified when a submission comes in through a portal, and can edit the submission's answers. Being on the list does not by itself put anything in anyone's work queue.
</Card>
<Card title="Submission reviewer" icon="user-check">
Set from the **Assign reviewer** picker at the top of a submission. One person or one user group per submission. This is who gets the work queue item on the Overview page once the vendor submits. Assessment questionnaires do not have one; they are reviewed through the assessment.
</Card>
</CardGroup>
When a questionnaire is sent, the submission reviewer is seeded automatically. If the template names exactly one reviewer, that person is used. If it names none, or several, the sender becomes the reviewer. A send from a portal template always uses the sender. Reassigning cancels the previous reviewer's open item and, if the vendor has already submitted, creates one for the new reviewer. Accepting or denying completes the decider's item and cancels everyone else's.
A derived questionnaire inherits its reviewers from the control set. The dialog reads **View Reviewers** and shows them read-only with **Go to Control Set**.
## Sending a questionnaire
A questionnaire reaches a vendor through a portal: a branded page with a due date, your message, and the questionnaire as a required item. Which button you use depends on the type.
<Steps>
<Step title="Informational and Know-Your-Vendor: send from the template">
Click **Send Questionnaire** at the top right of the template, pick a vendor under **Select a Vendor**, and the portal is created with the due date one week out. The portal details drawer opens so you can adjust the due date and message and copy the link. The button is disabled while the template has unsaved changes or while a select question has no options; the tooltip names the questions.
</Step>
<Step title="Inherent risk: send from the vendor page or collect at intake">
On a vendor's **Overview**, the **Inherent Risk** card offers **Send IRQ**, with **Send questionnaire directly** (pick a template, portal created for one week) or **From template** (a saved portal template). The same card exists on a service and on an engagement, which scopes the score to that record. An IRQ also runs inside vendor intake; see [Requesting a vendor](/user-guides/requesting-a-vendor).
</Step>
<Step title="Assessment: send through the assessment plan">
Assessment questionnaires are not sent from here. They go out with the assessment's portal when the plan includes them. See [Running an assessment](/user-guides/running-an-assessment).
</Step>
</Steps>
Sending needs the `portal:create` permission. The vendor receives the portal invitation email described in [Email notifications](/user-guides/email-notifications).
### What the vendor sees
The portal shows your message, the due date, and a list of required items on the left. Each question shows its title and instructions, a red marker with the tooltip **Required** where you set it, a comment box labeled **Comments (Optional)** or **Comments (Required)**, and a **Supporting Documents** picker where attachments are allowed. Sections and questions hidden by conditional logic do not appear. Internal-only questions do not appear. Answers are **Auto-saved** as the vendor types.
The **Submit** button stays disabled until every required question is answered. Below it, **Complete all required questions to submit** scrolls to the first unanswered required question and marks each unanswered one **This question is required.** Hover the progress ring beside a questionnaire to see how many required questions are answered. Optional questions left blank do not block submission. After submitting, the vendor sees **Thank you** and the portal is closed to them; a vendor who returns later sees **This portal is closed**.
## Reading the submissions list
Open a template and its **Submissions** tab lists every send. The tab is the default whenever there is at least one submission. Search by vendor or respondent email.
| Column | What it shows |
| - | - |
| **Vendor** | The vendor the questionnaire was sent to. |
| **Scope** | IRQ only. The engagement or services the IRQ covers, or a dash when it covers the vendor alone. |
| **Respondent** | Who answered. **Self-reported** means the email was typed by the respondent and not verified by sign-in. |
| **Reviewer** | The submission reviewer, or **Unassigned**. |
| **Sent**, **Due date** | When the portal was created and when it is due. |
| **Status** | See the table below. |
| **% Complete** | Answered questions as a share of the visible questions. |
| **Score** | IRQ only. The inherent risk score, shown when numerical scores are on for your organization. |
| Status | Meaning |
| - | - |
| **Pending** | Sent, not yet submitted. Also the state after **Reopen Submission**. |
| **AI drafting** | AI is drafting answers from the files uploaded to the request and, unless the respondent turned it off, public information about the vendor. |
| **AI drafted** | Drafting finished. The respondent reviews the drafts and answers the questions the files did not cover before submitting. |
| **AI drafting failed** | Drafting stopped, for example because no file could be read. The respondent can try again or answer by hand. |
| **Submitted** | Answers received; the status moves on within moments. Assessment questionnaires go straight to **Accepted**, every other type to **Ready for review**. |
| **Ready for review** | Submitted and waiting for your decision. This is what creates the work queue item. |
| **Accepted** | Approved. Write-backs and the IRQ score have been applied. An assessment questionnaire lands here on submit, because it is reviewed through the assessment. |
| **Rejected** | Denied. |
<Frame>
<img alt="The Submissions tab of an inherent risk questionnaire listing vendors with status badges, reviewers, and scores" />
</Frame>
## Reviewing a submission
Click a row to open it. The header carries the **Assign reviewer** picker, the **Accept** and **Deny** buttons while the status is **Ready for review**, and an actions menu. On an intake request, **Request Clarification** sits beside them and emails the requester with a subject of **Clarification for Intake Request**. The tabs are **Summary**, **Review Questionnaire**, **Documents**, **Vendor Intelligence** and **Activity**, and the first two do the work.
<Frame>
<img alt="A questionnaire submission open on the Summary tab with the reviewer picker, Accept and Deny buttons, and the suggested risk profile card" />
</Frame>
<Steps>
<Step title="Read the Summary tab">
On an IRQ, the **Suggested Inherent Risk Profile** card shows the overall score and the per-domain scores the answers produce, and lets you adjust them before accepting. A **How this score was weighted** table appears when your risk domains carry weights, and names any answered questions that were not weighted. A notice explains when an option's minimum score override raised the score. The **Suggested updates** panel lists every write-back the answers propose, one row each with **Apply** and **Don't apply**, plus **Accept all** and **Reject all**; expand a row for **Why this was suggested**. A row marked **Applied on approval without review** has review turned off on its rule. The tags panel sits beneath it, and an AI summary of the answers at the bottom.
</Step>
<Step title="Check the answers on the Review Questionnaire tab">
Every question with its answer, comment, and attachments, grouped by section. Internal-only questions carry an **Internal only** badge and are yours to answer here. As a template reviewer or an administrator you can change answers; a callout says so and **All revisions will be tracked**. When someone on your own team filled in the questionnaire for the vendor, a callout says it was answered on the vendor's behalf. A changed answer shows **Response modified from the original by** and a **Version History** dialog keeps every version.
</Step>
<Step title="Decide">
**Accept** opens a dialog that can also set the vendor's status and launch an assessment against a plan. Both start off, so accepting applies the answers and nothing else until you turn one on. On an IRQ, the vendor's inherent risk score changes only when you accept, never when the vendor submits. **Deny** opens **Deny intake request?**, which can set a canceled status on the vendor. Either button is disabled, with the count shown, while a required internal-only question is unanswered. Suggestions you did not decide are applied on accept; rejecting by default would lose data every time someone approves quickly.
</Step>
</Steps>
<Warning>
Nothing from a write-back reaches the vendor or assessment until you click **Accept**. If the answers changed after you decided on a suggestion (autofill re-ran, or a reviewer edited the answer), your earlier decision no longer applies and the row reads as undecided.
</Warning>
The actions menu on a submission:
| Action | What it does |
| - | - |
| **Reopen Submission** | Reopens the portal and puts the submission back to **Pending**, so the vendor can answer new questions that were added. Shown on **Ready for review** and **Accepted** submissions that came through a portal. Needs `portal:update`. |
| **Mark as Pending Review** | Reverts an **Accepted** or **Rejected** decision to **Ready for review** so it can be decided again. |
| **View template** | Opens the template in a new tab. |
| **Export as XLSX** | Downloads this submission's answers. |
| **Configure Portal**, **Go to Portal**, **Copy Portal URL** | Portal actions for the send that carried the submission. |
| **Archive Submission** | Removes the submission from the list and cancels its work queue items. |
Returning a questionnaire to the vendor with a revision message is an assessment feature, not a submission action here. See [Reviews and approvals](/user-guides/reviews-and-approvals).
## Questionnaire history on the vendor page
A vendor's **Questionnaires** tab lists every questionnaire that vendor has ever been sent: from the vendor page, from intake, from an assessment, from a workflow, or for a service. Submissions on a template that was later deleted still appear, because deleting a template does not undo the sends made from it.
<Frame>
<img alt="A vendor's Questionnaires tab listing questionnaires with type, status, sent and submitted dates, assessment, and reviewer columns" />
</Frame>
| Column | What it shows |
| - | - |
| **Questionnaire**, **Type** | The template and its type. |
| **Status** | Same badges as the submissions list. |
| **Sent** | When the portal that carried it was created. A submission created by an assessment or workflow, with no portal, shows its own creation date. |
| **Submitted** | When the vendor submitted. Blank until they do, and blank rows sort last whichever direction you sort. |
| **Assessment** | The assessment it belongs to, if any. Clicking it opens the assessment; clicking anywhere else on the row opens the submission. |
| **Due Date**, **Respondent**, **Reviewer**, **Vendor**, **Last Updated** | As on the submissions list. |
Every column sorts, the filters are the same unified filters as elsewhere, and **Clear filters** keeps the tab scoped to the vendor. A reader whose questionnaire access is limited to assigned records sees only submissions of questionnaires they review.
## Versioning: edits are not retroactive
Saving a template after changing a question's text, instructions, guidance, response type, required flag, or scoring mode, or an option's name, description, value, or score override, creates a new version of that question. Existing submissions keep the version they were answered against, and the submission page renders each one against the questions it was asked. Conditional logic rules move to the new version with it.
Changing a question's settings (comments, documents, internal only, intake switches) or its position edits the question in place, because none of those invalidate an answer already given.
What this means in practice:
* Re-weighting an IRQ does not rescore vendors already accepted. Send a new IRQ, or run a reassessment, to apply the new weights.
* A vendor who is mid-way through a portal keeps the questions they started with. Use **Reopen Submission** after they submit if you need them to see questions you added.
* Deleting an option archives it. Submissions that selected it still show it.
## Notifications
| Event | Who is notified | How |
| - | - | - |
| A questionnaire is submitted through a portal | Every template reviewer | In-app and email, **Questionnaire submitted through portal**. Several submissions within five minutes are grouped into one email. The link goes to the assessment when there is one, otherwise to the Questionnaires page. |
| A submission reaches **Ready for review** with a reviewer assigned | The submission reviewer | A work queue item on their Overview page, and the **Work queue item assigned** notification. |
| A questionnaire is sent | The vendor | The portal invitation email. |
Each person controls these under their notification settings; see [Email notifications](/user-guides/email-notifications). A submission with no reviewer, or no vendor, creates no work queue item for anyone.
## Troubleshooting
| What you see | What is happening |
| - | - |
| "I added someone under Configure Reviewers and it never appeared in their work queue." | Template reviewers are a notification list. Assign them on the submission with **Assign reviewer**, or make them the template's only reviewer before sending so the send picks them up. |
| "The submission is Ready for review but nobody has a work queue item." | It has no submission reviewer. Assign one; the item is created immediately because the vendor has already submitted. |
| "The same template landed with different reviewers on two sends." | A send from a portal template always assigns the sender. A direct send honors a template with exactly one reviewer. |
| "Accept and Deny are grayed out." | A required internal-only question is unanswered. The tooltip gives the count. Answer it on the **Review Questionnaire** tab. |
| "Every vendor scores low." | Option values are still `0`. Weight every option on the template, then send a fresh IRQ; accepted submissions keep the old weights. |
| "A write-back I configured never changed the vendor." | Either the submission has not been accepted, the suggestion was rejected on the **Suggested updates** panel, or the target already held a value someone typed. Built-in columns are only filled when empty. |
| "The vendor cannot see a question I added." | They opened the portal before you saved it. After they submit, use **Reopen Submission**; they will see the new questions. |
| "Configure Conditional Logic is disabled." | The template has unsaved changes, or you lack permission. Save first. On a derived questionnaire the rules belong to the control set. |
| "An imported row says its ID could be any of two questions, such as 1.1 and 1.10." | Excel stored the ID as a number and dropped the trailing zero. Format the ID columns as text, type the IDs again, and upload the file again. The IDs on the template's **Questions** sheet are already text, so copying them avoids this. |
| "Rows from Current rules say the rule was changed or deleted after the sheet was exported." | Someone edited or deleted that rule in the dialog after you downloaded the file. Download **Current rules** again and redo your edits, or clear the Rule cell to add the row as a new rule. |
| "An imported row says the rule would make a loop." | The question the row shows already decides, directly or through other rules, whether its trigger question appears, so neither could be answered. The message names both questions. Change which question triggers one of the rules, or remove the rule that closes the loop. |
| "Send Questionnaire is disabled." | Unsaved changes, or a select question with no options. The tooltip lists the questions to fix. |
| "This questionnaire is no longer available." | The link points at a template that was deleted. Its submissions are still on each vendor's **Questionnaires** tab. |
| "Questionnaire changed" dialog while editing. | Someone else saved the template. Reload to get their version; your unsaved edits are lost. |
## Related
<CardGroup>
<Card title="The IRQ library" icon="clipboard-list" href="/user-guides/irq-library">
The packaged inherent risk templates, every question they ask, and how the score is calculated.
</Card>
<Card title="Admin setup" icon="sliders" href="/user-guides/admin-setup">
Tags, scales, and weighting the IRQ before your first intake.
</Card>
<Card title="Requesting a vendor" icon="inbox" href="/user-guides/requesting-a-vendor">
The intake flow where requesters answer the IRQ and analysts review it.
</Card>
<Card title="Running an assessment" icon="list-check" href="/user-guides/running-an-assessment">
Assessment questionnaires, the vendor portal, and follow-up rounds.
</Card>
</CardGroup>
# Working Radar signals
Source: https://docs.coverbase.com/user-guides/radar-signals
How to read the Radar signal queue, triage a signal into a case, a finding, a reassessment or an acknowledgement, keep sources and detectors tuned, and follow a signal into findings, the risk register, workflows and dashboards.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers everything under **Radar** in the left navigation and its settings under **Configuration → Radar**. For what the product is, see [Supplier Radar](/products/supplier-radar). For the one source that has its own setup page, see the [Black Kite monitoring guide](/user-guides/black-kite-monitoring).
</Info>
<Note>
Radar is an optional module. If you do not see **Radar** in the left navigation, ask your Coverbase representative to turn it on.
</Note>
Radar reads external sources (news, advisories, vulnerability databases, sanctions lists, your own feeds) and turns each event that touches one of your vendors into a **signal**. A signal carries a status, a severity, a summary written for your portfolio, and the list of your vendors exposed to it. Your job is to decide which signals become work and to teach the detectors to stay quiet about the rest.
Two settings do the monitoring. A **source** collects. A **detector** decides what is worth an alert. A source with no detector fills up quietly and never tells anyone. A detector with a loose threshold fires on every routine patch note. Most Radar problems are one of those two.
## The vocabulary
| Term | What it is | Where you see it |
| - | - | - |
| **Source** | Your subscription to one feed, API, page or portfolio. Most sources come from the shared library. A source you add by URL is yours alone. | **Configuration → Radar → Sources** |
| **Detector** | A rule for what deserves an alert: plain-language guidance, a severity threshold, category and source filters, and the vendors it applies to. | **Configuration → Radar → Detectors** |
| **Signal** | One event, as it affects your organization. One signal per event, however many detectors fire. | **Radar → Signals** |
| **Alert** | One detector's verdict that an event matters for one of your vendors, with severity, confidence and reasoning. Alerts sit under the signal on its **Detectors** tab. | The signal page |
| **Case** | An investigation you open from a signal, with one thread per vendor and vendor outreach. | **Radar → Cases** |
| **Finding** | A confirmed problem on a vendor, created from a signal. | **Findings**, and the vendor page |
| **Reassessment** | A draft batch of assessments raised from a signal or a trigger, run once you confirm the vendors. | **Radar → Reassessments** |
The chain is: a source pulls an item, Radar folds the item into an event, the event touches one of your vendors and becomes a signal, each enabled detector that targets that vendor reads the event and either alerts or stays quiet, and an alert at or above the detector's severity threshold puts the signal **In alert**. An Informational alert never does.
## Where things live
**Radar** in the left navigation opens the **Portfolio risk** chart (once there are signals to plot) and three tabs: **Signals**, **Cases** and **Reassessments**. At the right of the tab bar, the **Configurations** menu links to the three tabs of **Configuration → Radar**: **Detectors**, **Sources** and **Reassessments** (the reassessment triggers). Beside it, **New detector** offers **From detector library** and **Create custom detector**, and under **Also add**, **Source from library** and **Log a signal manually**.
Every vendor page also has a **Radar** tab. It lists **Detectors monitoring this vendor** and the vendor's **Recent alerts**, with an **Edit detector** link on each detector.
## The signal queue
Open **Radar → Signals**.
<Frame>
<img alt="Radar Signals tab listing signals with severity, status, vendors and detectors" />
</Frame>
Three built-in views sit in the view selector. **All Signals** is the default and shows everything, newest first. **In Alert** shows only signals with an active alert, most recently alerted first. This is the queue. **Triaged** shows signals someone has already acted on. Search signal titles and summaries, add filters, change sorting and columns under **Display**, and save the arrangement with **New view**.
| Column | What it shows |
| - | - |
| **Severity** | The highest severity any detector assigned to this event. |
| **Signal** | The title Radar wrote for your organization. |
| **Status** | Where the signal stands. See the table below. |
| **Vendors** | Your vendors linked to the event. |
| **Detector** | The detectors that fired. |
| **Last alerted** | When the most recent alert attached. |
| **Risk domains** | The domains the firing detectors map to. |
| **First seen** | When Radar first saw the event. |
| **Nth Parties**, **Nth Party Tags** | The companies your vendors depend on that the event names, and their tags. Hidden by default; turn them on under **Display**. |
Rows group by **Today**, **Yesterday**, **This week**, **Last week** and **Older**. The icon button beside **Display** collapses or expands every group. The **Actions** menu offers **Download as Excel**: the **Export Signals** dialog exports every signal in the view with the table's visible columns, and lets you also include the summary, notes and detector results.
To record an event by hand, choose **New detector → Log a signal manually**. Give it a **Title** and **Summary**, and optionally the **Impact area**, **When it occurred**, **Risk domains**, a **Source URL** and **Source name**, and the **Affected vendors**. **Create signal** opens the new signal, and the detectors evaluate it like any other event.
### Signal statuses
| Status | Meaning |
| - | - |
| **Tracked** | A vendor you depend on is linked to the event, but no detector has alerted. Radar shows the exposure and waits. |
| **Open** | No detector is alerting, but someone handled the signal by hand: created it, edited it, or restored it after a dismissal. |
| **In alert** | At least one detector fired at or above its threshold and the alert is still active. |
| **Triaged** | Someone acknowledged the signal, opened a case, created a finding, or started a reassessment. |
| **Dismissed** | Every alert on the signal was dismissed, or the signal was dismissed before any alert existed. |
| **Closed** | A terminal status. Nothing moves a signal here on its own; set it from the status card on the signal page. |
Your organization can add statuses of its own between these under **Statuses**, where the target type is **Radar Signal**.
### Acting on several signals at once
Tick rows and a bar appears with **Start reassessment**, **Acknowledge**, **Dismiss** (or **Restore (un-dismiss)** for dismissed rows), **Should have alerted** and **Clear**. **Should have alerted** is for a Tracked signal a detector missed: pick the detector, and the signal is added to it as a positive example so events like it alert next time.
## Reading a signal
Click a row. The page opens with the title (click it to edit), the severity badge, a **Vulnerability** badge when the event is a CVE, and the **Actions** menu.
<Frame>
<img alt="Radar signal page showing the status card, vendors card, summary and Detectors tab" />
</Frame>
The left column holds:
* The **status card**, named after the current status. Anyone with update permission on alerts can set a different status here.
* **Triage actions**, once any exist: **Marked as acknowledged**, and the cases, findings and reassessments raised from this signal, each linking to its record.
* **Vendors**: how many of your vendors were exposed, with **View full exposure** opening the Exposure tab.
* **Vulnerabilities**, on a CVE event: **Potential impact (CVSS v3.1)**, **Likelihood of exploitation (EPSS)** and **Known exploited (KEV)**. A blank EPSS is common; a blank KEV means no source reported either way.
The main column holds:
* **Summary**, with the **Risk type** chips. Click the pencil to rewrite it by hand. **Regenerate summary** rewrites it from what the detectors currently report and discards any hand edit. **Custom AI instructions** on this card apply to every generated summary in your organization.
* **Ask Coverbase AI**, which can see the event, the exposed vendors, this signal's triage, and other alerts from the past year.
* **Time to signal**: **Event occurred**, **First public disclosure** and **Coverbase alert sent**, with the gaps between them.
Below those, six tabs:
| Tab | What it holds |
| - | - |
| **Detectors** | One card per alert: the detector, the vendor, severity, confidence, when it alerted, its reasoning, and the sources it cited. Group by **Detector**, **Severity** or **Vendor**. Each card has its own **New finding**, **Acknowledge** and **Dismiss** actions, and a **Rate this result** pair of thumbs that adds the event to the detector as a positive or negative example. |
| **Exposure** | Every vendor the event touches, with **Tier**, **Inherent risk**, **Residual risk**, **Triage** (what has been done for that vendor) and **Exposure** (**Direct** or **Nth Party**). Switch between **Your vendors** and **All related entities**, and between the **Table** and the **Flow** view. **Add vendor** links a vendor Radar missed. |
| **Sources** | The articles, API records and snapshots behind the event, each with **Published** and **Fetched** times. |
| **Timeline** | Everything in order: sources linked, detections, dismissals, triage. |
| **Notes** | Notes on the signal. |
| **Activity** | The audit trail, including system entries. |
An **Nth Party** exposure means one of your vendors depends on a company the event names. Those relationships come from SOC 2 reports and subprocessor lists, so one event can implicate vendors nobody mentioned. A vendor whose uploaded SBOM lists an affected component shows as **Direct**, with the matched components in a **Source** column; see [Bills of materials](/user-guides/bill-of-materials#what-you-see).
## Triaging a signal
Open the **Actions** menu on the signal page. What it offers depends on where the signal stands.
| Action | What it does | Status afterwards |
| - | - | - |
| **Open case** | Starts an investigation with one thread per affected vendor. Shown only while the signal has no open case. | Triaged |
| **Bulk create findings** | One finding per vendor you tick, prefilled from the alert. | Triaged |
| **Start reassessment** | Drafts a reassessment for the exposed vendors, with an optional assessment plan. | Triaged |
| **Acknowledge** | Records that you saw it and no case or finding is needed. | Triaged |
| **Dismiss** | Closes the alerts as not needing action, with an optional reason. | Dismissed |
| **Restore (un-dismiss)** | Brings a dismissed signal back. | In alert |
**Bulk create findings** and **Start reassessment** are disabled when the signal has no exposed vendors. **Acknowledge** disappears once the signal is Triaged or Dismissed.
### Dismissing
<Frame>
<img alt="Dismiss signal dialog with a reason field, the alerted detectors, and the signal's alerts all selected" />
</Frame>
The dialog names the **Alerted Detectors** with how many alerts each raised, then lists the signal with a count such as **22 of 22 alerts**. Every active alert is ticked. Expand the signal (or **Expand all**) and untick the alerts you want to keep, and the button changes from **Dismiss signal** to **Dismiss N alerts**; the signal itself is dismissed only when every alert is. Type a **Reason (optional)** if you want one on the record. Mention a colleague in it and they get a **Dismissal mentions** notification.
Each dismissed alert also becomes a negative example on the detector that raised it, with your reason attached, so events like it stay quiet next time. That happens only when you can edit detectors; a dismissal by someone who cannot closes the alerts and teaches nothing. **Restore (un-dismiss)** takes the example back out. Dismissing is the main way a detector learns; the others are the thumbs on each alert and the detector's own **Test detector** run, below.
### Opening a case
**Create a Case** asks for a **Title** (prefilled with the signal title), a **Description** (prefilled with its summary), and the **Affected Vendors**. **Include all affected vendors** is on by default. **Create and Continue** takes you to **Send Emails**, where a **Shared Draft Template** with placeholders for the vendor name and your organization name can be applied to every pending vendor, edited per vendor, and sent one at a time or with **Send all remaining**. **Skip and Go to Case** leaves the emails for later.
The case page has **Overview**, **Vendors**, **Notes** and **Activity** tabs, with **Send Emails**, **Add Vendors** and **Finalize Case** at the top and **Export as Excel**, **Import Vendors** and **Archive Case** in the menu beside them. Each vendor thread carries a status, an assignee, a due date and the vendor's replies. **Finalize Case** asks how the case was resolved: **Resolved**, **Won't fix** or **False positive**. The first two raise the affected vendors' residual risk when the detectors that fired are set to update risk; **False positive** moves no risk. While vendor threads are still open, the same dialog offers **Close case and threads** or **Close case only** to leave them as they are. **Reopen Case** undoes a close and clears the resolution. **Archive Case** is final.
### Starting a reassessment
**Start a reassessment** lists the exposed vendors. Remove any you do not want, **Add vendor...** for one Radar missed, optionally pick an **Assessment Plan**, and click **Start a reassessment**. The draft opens on its own page and is listed under **Radar → Reassessments**. Check the vendors and the plan there, then **Run reassessment**, which creates one assessment per vendor from the plan. **Dismiss** closes the draft without running it. Reassessments can also be raised without a person, by the triggers under **Configuration → Radar → Reassessments**: each trigger names a plan, a vendor scope, and either risk-score conditions or an **AI event-type instruction** describing the kind of signal that should trigger it.
### The risk review
When a firing detector has **Residual risk impact** switched on, acknowledging, creating a finding, starting a reassessment, or finalizing a case raises the affected vendors' residual risk. **Review vendor risk profile updates** opens with the new scores, overall and per domain. Adjust any of them and **Save and continue**, or **Continue** to accept. Dismissing never moves risk. How the size of the move is chosen is on the [Supplier Radar page](/products/supplier-radar#risk-propagation).
## Sources
Open **Configuration → Radar → Sources**.
<Frame>
<img alt="Radar sources list with Name, Type, Date Added, Last Fetched and Status columns" />
</Frame>
The table shows **Name**, **Type** (**Article feed**, **RSS feed**, **API**, **Snapshot**, **Black Kite** and so on), **Date Added**, **Last Fetched** (**Never** until the first successful run) and **Status**. Search by name or filter the list. The row menu has **Archive**, which stops collection and cannot be undone. Archived sources keep the items they already collected.
**Add source** offers three routes:
* **From Source Library**: tick sources in the curated catalog, narrowed by segment or search (**Add all visible** ticks everything in view), then **Connect**. A source Coverbase has withdrawn is greyed out as **Unavailable**, with the reason. The full list is on the [source library page](/products/source-library). Library sources are shared and run on a schedule Coverbase sets; you can rename one but not change how it fetches.
* **Black Kite portfolio**: covered in the [Black Kite monitoring guide](/user-guides/black-kite-monitoring).
* **New Custom Source**: your own **Article Feed** (a news page or RSS feed), **API** (a JSON endpoint with a request configuration and a response mapping), or **Snapshot** (a page or a JSON list watched for changes, with a **Fetch Schedule** of **Hourly**, **Every 4 hours**, **Daily** or **Weekly**).
| Source status | What it means |
| - | - |
| **New** | Not saved yet. |
| **Pending** | Saved, and Radar is still building the extractor that reads the page. RSS feeds skip this and go straight to Active. |
| **Active** | Collecting. |
| **Unsupported** | Radar could not build an extractor for this page. It will not be monitored. |
| **Setup incomplete** | Extractor generation was abandoned. Reopen the source and finish it. |
| **Paused** | Collection has stopped for this feed, usually because Coverbase withdrew a library source whose page no longer exists or refuses automated requests. Items already collected stay. |
A custom Article Feed without an RSS feed needs a generated extractor. The source page shows sample extracted items for you to **Accept** or **Reject**, and stays quiet until one is accepted.
### A source's items and runs
Click a source. Besides **Configure**, it has an **Articles** tab (**Snapshot** on a snapshot source) and a **Runs** tab.
<Frame>
<img alt="Source Runs tab listing fetch runs with status, duration and item counts" />
</Frame>
**Articles** lists every item the source collected, with its **Categories** and **Date Ingested**. Click one to read it and see which detectors evaluated it. **Runs** lists each fetch with **Status**, **Date Started**, **Duration**, **Fetched**, **Summarized**, **Entities**, **Detections** and **Errors**. Click a run for its log. A source that runs successfully with zero **Fetched** for days is usually a feed that has stopped publishing, or a page that started blocking automated access.
## Detectors
Open **Configuration → Radar → Detectors**.
<Frame>
<img alt="Radar detectors list with Title, Categories and Reviewers columns" />
</Frame>
New organizations start with a recommended set already enabled, announced by a banner on the Radar page and a **Suggested actions** checklist here: review the recommended detectors, customize the vendor scope, assign default reviewers, disable what is not relevant, add more. **Mark as complete** hides the checklist.
The table shows **Title**, **Categories** and **Reviewers**. When any detector is disabled, **Enabled** and **Disabled** tabs appear with counts. The row menu has **Enable** or **Disable** and **Archive**. Tick several rows for **Assign reviewer**, **Disable** and **Archive** in bulk. Archiving cannot be undone; disabling can.
### Adding one
**Add detector** (or **New detector** on the Radar page) offers **From detector library** and **Create custom detector**.
<Frame>
<img alt="Detector library dialog with segment chips, a list of templates and a preview showing guidance and sources" />
</Frame>
The library filters templates by **All**, **Recommended** and segment (**Cybersecurity**, **Financial**, **Operational**, **Legal**, **Compliance**, **Reputational**, **Contractual**, **ESG**, **Corporate**, **Geopolitical & External**, **AI Risk**). Click a template to preview its **Guidance**, the **Sources** it deploys with, and an **Example**. **Add detector** adds it with its recommended settings; **Configure** adds it and opens it for editing. On a template you already have, the button reads **Enable detector** or **Disable detector**. Tick several and **Enable** them at once. Every template is listed with its default severity on the [detector library page](/products/detector-library).
Enabling a template adds its sources to your organization, where you do not already have them, and scopes the new detector to them, so it starts working without further setup. A source marked **Unavailable** has been withdrawn and is skipped. A template becomes an ordinary detector on your organization, so everything below applies to it, including changing its sources.
### The detector form
<Frame>
<img alt="Detector editor showing vendor targeting, severity threshold, guidance and risk impact" />
</Frame>
| Field | What it does |
| - | - |
| **Name**, **Description** | How the detector appears in lists, on alerts and in notification emails. |
| **Sources** | Restrict the detector to specific sources. Empty means every source. A detector added from the library starts limited to the sources it deployed with, so a source you add later is not read by it until you add it here. A detector limited to sources sees events you record by hand only if it includes **Manually-created events**. |
| **Vendor targeting** | **Apply to all vendors**, or tag conditions: a vendor matches a condition when it has all of that condition's tags, and conditions are combined with OR. **Include specific vendors** adds named vendors. **Exclude vendors** always wins. |
| **Categories** | Restrict to impact types (Infosec, Financial, Operational, Legal, Compliance, Reputational, Contractual, ESG, Corporate, Geopolitical & External). Empty means all. |
| **Severity Threshold** | **No threshold**, **Informational**, **Low**, **Medium** or **High**. An alert is raised when the detected severity meets or exceeds it. |
| **Guidance** | Plain-language instructions on what to flag and how severe it is. **AI autofill** drafts it from the name and description. Either guidance or a threshold is required. |
| **Residual risk impact** | Off by default. When on, acting on one of this detector's alerts raises the vendor's residual risk by a value between **Min impact** and **Max impact** (0 to 100), on the overall score when **Affect overall residual risk** is on, and on the mapped **Risk domains**. |
| **Positive examples**, **Negative examples** | Events the detector should and should not alert on. Dismissals and thumbs ratings land here. Remove an example to make the detector reconsider. |
| **Default Reviewers** | Users and user groups notified of every alert. **Send test alert** sends one notification to them, once the detector is saved with at least one reviewer. |
| **Detector enabled** | Off keeps the settings but stops evaluation. |
Two other detector kinds share the list. A **Watchlist detector** matches vendors deterministically against connected sanctions and watchlist sources, every 4 hours, and has no guidance, threshold or examples; it needs a watchlist source connected first. A **Black Kite detector** reads your Black Kite portfolio against thresholds, and is covered in its [own guide](/user-guides/black-kite-monitoring#step-4-create-a-detector).
### Testing before you enable
**Test detector** on a saved detector re-runs it against your recent events over the **Last 7 days**, **Last 30 days** or **Last 90 days**. Each result reads **Will alert** or **Will not alert**. Mark results **This should alert** or **This shouldn't alert**, then **Refine with AI** proposes a rewrite of the guidance, which you can edit before **Apply & re-run**. Tick results and **Create alerts** to turn them into real alerts; a result that already has a live alert is skipped.
<Tip>
Start narrow. Keep the threshold at **Medium** or **High**, target the vendors you would act on, and watch two weeks of alerts before loosening anything. Every dismissal makes the detector quieter, so the first weeks are also when it learns fastest.
</Tip>
## Which vendors are watched
A vendor is evaluated by every enabled detector whose **Vendor targeting** includes it. That is the whole rule. The vendor page's **Radar** tab lists the detectors that currently apply, so it is the quickest way to answer "is this vendor covered?". A vendor with no detectors still gets **Tracked** signals when an event touches it, because tracking needs no detector.
Vendors also carry a monitoring flag, which a workflow's **Enable vendor threat monitoring** action turns on. That flag is what the **vendors monitored by Radar** count on your subscription uses, so it decides what monitoring costs, not what a detector watches. The same flag decides who [dark web monitoring](/user-guides/dark-web-monitoring#what-is-watched) watches when it is set to follow Radar.
## Notifications
Radar sends four notifications. Each person can switch them on or off in their notification settings: **Radar detector alert** and **Reassessment trigger fired** sit in the monitoring group, **Case created** with cases, and **Dismissal mentions** with mentions.
| Notification | Who gets it | When |
| - | - | - |
| **Radar detector alert** | The detector's default reviewers | A detector raises an alert. In-app it reads as the severity, the summary and the vendor, with a **View alert** button. The email subject is the severity, "radar alert", the vendor and the summary; the body adds a line about the vendor, when the event was first found, the detector, and **Why this was flagged**. Alerts from one run within a minute of each other arrive as one email. |
| **Reassessment trigger fired** | The people named under **Notify** on the trigger | A reassessment trigger proposes a draft. |
| **Case created** | The default reviewers of the detectors that fired, plus each affected vendor's relationship owners and risk analysts | A case is opened from a signal. |
| **Dismissal mentions** | The person mentioned | Someone mentions them in a dismissal reason. |
A detector with no default reviewers raises alerts that nobody is told about. They still appear in **In Alert**. The full catalog is in the [email notifications guide](/user-guides/email-notifications#monitoring).
## Where signals go next
* **Findings.** A finding created from a signal carries the source type **Radar alert**, opens with the detector name and the alert summary as its title, and links back to the signal from the **Triage actions** card. From there it is an ordinary finding: see [Findings Manager](/products/findings-manager).
* **Vendor risk.** With **Residual risk impact** on, triage moves the vendor's residual score, and the vendor's risk history records the change and the detector behind it.
* **Risk register.** The register's **Signal Sources** settings can attach **Radar signals** and **Radar alerts** at or above a severity threshold to risks, and a risk's **Attach signal** button does it by hand. Turning a source off stops new attachments and leaves existing ones.
* **Workflows.** A workflow can trigger on a Radar signal, condition on its fields, and update it. The **Monitoring signal triage** [template](/user-guides/workflow-templates#monitoring-signal-triage) opens a review and a dated task for every new signal.
* **Dashboards.** The **Portfolio risk** chart on the Radar page plots signals over time by severity, with a **3M**, **6M**, **12M** or **All** range and vendor and tag filters; click a point for the affected vendors.
* **API and webhooks.** Events and alerts are readable and dismissable over the [Radar API](/api-reference/radar), and `RadarEvent.*` and `RadarDetectorResult.*` webhooks fire as they change.
## Who can do what
| Role (default) | Signals and alerts | Detectors and sources |
| - | - | - |
| **Admin** | Everything | Create, edit, test, enable, archive |
| **Member** | Read, triage (acknowledge, dismiss, restore, set status, edit title and summary) | Read only |
| **Siloed member** | Read | Read only |
Radar is org-wide: a siloed member sees every signal, not only their vendors' signals. Creating a case, a finding or a reassessment from a signal also needs the permission for that record. Custom roles can change any of this; see [Permissions and roles](/user-guides/permissions-and-roles).
## Troubleshooting
| What you see | What is happening |
| - | - |
| A source runs and **Fetched** climbs, but no signals appear. | No enabled detector targets the vendors in those items, or the detector's threshold is above what it is finding. Check the vendor page's **Radar** tab, then the detector's **Severity Threshold**. |
| A signal is **Tracked** and nothing happens. | That is the design. A related vendor is linked and no detector has alerted. Use **Should have alerted** to teach a detector, or act on it directly from **Actions**. |
| A dismissed signal is not under **Triaged**. | **Triaged** holds signals with a triage action. Open **All Signals** and filter **Status** to **Dismissed**, or **Restore (un-dismiss)** it. |
| Reviewers got no email for an alert. | The detector has no **Default Reviewers**, the reviewer switched **Radar detector alert** off in their settings, or the alert is Informational and did not put the signal in alert. |
| **Acknowledge** is missing from the menu. | The signal is already Triaged or Dismissed. |
| **Bulk create findings** is grayed out. | The signal has no exposed vendors. Add one on the **Exposure** tab first. |
| **Send test alert** is disabled. | Save the detector first, and add at least one default reviewer. |
| A detector alerted on the same event twice. | It fired for two different vendors. Each alert is one detector on one vendor, and both sit under the same signal. |
| A library source cannot be edited. | Library sources are shared. You can rename them; for different settings, create a custom source. |
| A detector from the library ignores a source you added later. | It is scoped to the sources it deployed with. Add the new source under the detector's **Sources**. |
| A dismissal did not stop similar alerts. | The person who dismissed it cannot edit detectors, so nothing was taught. Ask an admin to add the event as a negative example on the detector. |
## Related
<CardGroup>
<Card title="Supplier Radar" icon="satellite-dish" href="/products/supplier-radar">
What the product does, the signal lifecycle, and how triage moves residual risk.
</Card>
<Card title="Black Kite monitoring guide" icon="shield-halved" href="/user-guides/black-kite-monitoring">
Connecting a Black Kite portfolio as a source and alerting on its findings.
</Card>
<Card title="Detector library" icon="radar" href="/products/detector-library">
Every template with its default severity and what it flags.
</Card>
<Card title="Workflow templates" icon="diagram-project" href="/user-guides/workflow-templates">
Enrolling vendors in monitoring and routing new signals into reviews and tasks.
</Card>
<Card title="Dark web monitoring guide" icon="mask" href="/user-guides/dark-web-monitoring">
Leak sites, breach catalogs, infostealer logs and lookalike domains for your organization and your vendors.
</Card>
</CardGroup>
# Confirm inherent risk before a reassessment
Source: https://docs.coverbase.com/user-guides/reassessment-irq-review
Turn on the inherent risk check for an assessment plan, see what the relationship owner receives, read the owner's changes on the assessment, confirm or skip the check, start a reassessment by hand with or without it, and fix the common reasons a check does not go out.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Before a Reassessment Starts** setting under **Configuration → Assessment Settings** and the **Inherent Risk Check** card on an assessment. It sits beside [Running an assessment](/user-guides/running-an-assessment) and [IRQ Library](/user-guides/irq-library). For the plans and cadence it builds on, see [Admin setup](/user-guides/admin-setup#step-7-assessment-plans-and-reassessment-cadence).
</Info>
A reassessment usually starts from the vendor's inherent risk as it was last time. When the relationship has changed (new data, new access, a new use), the vendor gets last year's questionnaires. The inherent risk check closes that gap: before anything goes to the vendor, the relationship owner re-answers your IRQ, prefilled with the answers you approved last cycle. The plan then picks questionnaires and control sets from the refreshed inherent risk.
The mistake people make most often is expecting the check on every assessment. It runs only on reassessments created from a plan that has it turned on: the scheduled reassessment, a Radar reassessment run, and a reassessment you start by hand with the box left checked. A reassessment means the vendor has a completed assessment, or a last assessed date brought over from another platform. A vendor's first assessment always starts right away, because there is no earlier answer to confirm.
## How it works
<Steps>
<Step title="The reassessment is created and waits">
The reassessment is created from its plan on schedule, from Radar, or by hand. It stays in **Created**. No vendor portal goes out and no analysis runs.
</Step>
<Step title="The relationship owner gets the IRQ">
Coverbase emails the vendor's relationship owners a link to the IRQ, with last cycle's approved answers filled in. A reassessment for one service goes to that service's relationship owners, then the vendor's.
</Step>
<Step title="The owner confirms or changes each answer">
The owner clicks **Confirm all** for answers that are still true and changes the ones that moved. They cannot submit while a carried-forward answer is unconfirmed.
</Step>
<Step title="Coverbase or the assignee decides">
If the owner kept every answer, Coverbase approves the IRQ and the assessment starts on its own. If anything changed, the assessment's assignee reviews the changes and clicks **Confirm and start assessment**.
</Step>
<Step title="The assessment starts">
Confirming approves the IRQ onto the vendor the same way any IRQ approval does: inherent risk scores, tags and contacts update. The plan is then applied again, so its rules pick questionnaires and control sets from the new inherent risk, and document collection begins.
</Step>
</Steps>
## Step 1: Turn on the check for a plan
Open **Configuration**, choose **Assessment Settings**, and open the plan your reassessments use. Changing a plan needs a role that can change organization settings.
<Steps>
<Step title="Choose Confirm inherent risk first">
Under **Before a Reassessment Starts**, choose **Confirm inherent risk first**. **Start right away** keeps today's behavior.
</Step>
<Step title="Pick the IRQ">
Choose the **Inherent Risk Questionnaire** to send. Use the IRQ your intake uses, so the owner sees the same questions they answered before and their answers carry forward. If you publish a new version of it, sends use the published version.
</Step>
<Step title="Set how long the owner has">
**Due After** is the number of days before the owner's link is due. The default is 14. Portal reminders apply as they do for any IRQ.
</Step>
</Steps>
Click **Save plan**. Reassessments created after the save use the check. Reassessments already in progress are not changed.
<Tip>
The IRQ goes out when the reassessment is created, which is the plan's **Document collection** offset before the reassessment date. Lengthen that offset by the owner's due window so the vendor still has the time it had before. See [Admin setup](/user-guides/admin-setup#step-7-assessment-plans-and-reassessment-cadence).
</Tip>
<Note>
A Zero Touch plan cannot use the check, because a Zero Touch assessment contacts nobody.
</Note>
## Step 2: Follow a reassessment that is waiting
Open the assessment. The **Inherent Risk Check** card on the **Summary** tab says who the check is waiting on, when it was sent and is due, and which approved IRQ the answers came from. The status card reads **Confirm inherent risk** above the assessment's phases.
From the card you can:
* Click **Open IRQ** to read the owner's answers so far.
* Click **Send to someone else** to send the IRQ to a different person, for example when the relationship owner is out. When no relationship owner has an email address, the button reads **Send IRQ** and nothing has been sent yet.
* Click **Skip and start assessment** to start without the check. See [Skip the check](#skip-the-check).
## Step 3: Review the owner's changes
When the owner submits with changes, the card reads **Ready for your review**. It shows:
1. How many answers the owner kept and changed.
2. The inherent risk level before and after, for example **High** to **Critical**.
3. Each changed answer, with the old answer struck through above the new one.
Click **Confirm and start assessment**. The assignee also gets a review item in their work queue for the IRQ; approving it from the submission page does the same as confirming on the card.
<Warning>
Confirming updates the vendor's inherent risk, which can change its reassessment cadence under your reassessment rules. It keeps the assessment's plan. To use a different plan for the new risk level, edit it on the assessment's **Plan** card while documents are still being collected.
</Warning>
## Skip the check
Click **Skip and start assessment**, give a reason, and confirm. The assessment starts on the vendor's current inherent risk. The IRQ stays open: if the owner answers later and you approve it, the vendor's inherent risk updates as it does for any IRQ. The card keeps who skipped and why.
## Start a reassessment by hand
Click **Start reassessment** on the vendor, or create an assessment from **Assessments**, and choose a plan that has the check. If the vendor has been assessed before, the dialog shows **Confirm inherent risk with the relationship owner first**, checked. Leave it checked for the check, or clear it to start right away.
## When the check does not run
| What you see | Cause | Fix |
| - | - | - |
| The card says the IRQ has not been sent | No relationship owner on the vendor (or the service) has an email address. | Add a relationship owner, or click **Send IRQ** and choose who to send it to. |
| The card says **No earlier answers to carry forward** | The vendor has no approved IRQ of this questionnaire to copy from. | Nothing to fix. The owner answers it from scratch, and the next reassessment carries their answers forward. |
| The card reads **Skipped** with a reason about engagements | The vendor's inherent risk is tracked per engagement, so a vendor-wide IRQ would not reach it. | Refresh each engagement's IRQ from its [monitoring plan](/user-guides/monitoring-plans). |
| The card reads **Skipped** saying the plan no longer asks for the check | The plan's setting was turned off after the reassessment was created. | Nothing to fix. The assessment started on current inherent risk. |
| No **Inherent Risk Check** card | The assessment was not created with the check: the plan has it off, the vendor had never been assessed, or the box was cleared when it was started by hand. | Turn the check on for the plan for future reassessments. |
| The owner cannot submit | An answer carried forward from last cycle is not confirmed yet. | The owner confirms or changes each carried-forward answer, or clicks **Confirm all**. |
| The assessment still says **Created** after confirming | The assessment is starting in the background. | Wait a moment and refresh. If your organization uses its own **Unstarted** statuses, the assessment moves to the first of them instead of starting collection. |
## Related
<CardGroup>
<Card title="Admin setup" icon="gear" href="/user-guides/admin-setup">
Assessment plans, reassessment rules and the reassessment timeline.
</Card>
<Card title="Running an assessment" icon="list-check" href="/user-guides/running-an-assessment">
What happens after the assessment starts.
</Card>
<Card title="IRQ Library" icon="book" href="/user-guides/irq-library">
Choosing and weighting the IRQ the check sends.
</Card>
<Card title="The vendor record" icon="building" href="/user-guides/vendor-record">
Setting relationship owners.
</Card>
</CardGroup>
# Requesting a new vendor
Source: https://docs.coverbase.com/user-guides/requesting-a-vendor
The requester's side of vendor intake: what you'll be asked, how to file a request in the portal or in chat, and what happens after you submit.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is for the person who wants to start using a new tool or vendor, not for the risk team reviewing the request. If you are on the reviewing side, see the [Analyst and reviewer guide](/user-guides/analyst-reviewer).
</Info>
Before anyone signs anything, your organization needs to know who the vendor is, what data they will touch, and whether you already pay for something that does the same job. That is what a vendor intake request is for, and it takes a few minutes.
Coverbase does most of the typing. You confirm, correct, and decide.
## Read this part first
<Warning>
**Submitting a request is not approval.** It does not authorize you to buy, sign, expense, or deploy anything.
</Warning>
When you finish, your request goes to your security or due diligence team, and they decide it. A vendor record may appear in Coverbase with your request attached, but it sits in **Created** status. It is not an approved vendor until someone reviews and accepts it.
A completed intake form means "asked", not "allowed". Wait for the decision before you commit spend or send data.
## Two ways to file one
<CardGroup>
<Card title="The portal" icon="browser">
A three-step form: **Select Vendor**, **Additional Information**, **Review Questionnaires**. Use the link your admin gave you.
</Card>
<Card title="Chat" icon="comments" href="/mcp/vendor-intake">
Ask an AI assistant connected to Coverbase. Same request, same queue, no form.
</Card>
</CardGroup>
They produce the same thing. Pick whichever you are already using.
To file in chat, say what you want in ordinary language. You do not need to use the word "intake":
> I want to start using Northwind Analytics for product analytics.
> My team needs a load testing tool and we're looking at Loadspin. Can we buy it?
> Is Acme approved for us to use?
That last one checks first and offers to file a request only if there is not already an approved record.
## What you'll be asked
<Steps>
<Step title="Which vendor, exactly">
Coverbase researches the company and shows you what it found: what they do, their website, their headquarters, their trust center. Check it. Two companies called Acme is common, and a request filed against the wrong one is sent back to you. If it is wrong, say so and correct it.
</Step>
<Step title="Whether you already have something that does this">
You are shown existing vendors in your portfolio that cover the same job, and any prior relationship with this vendor. Depending on how your admin configured things, you may also see alternatives found on the web.
If an approved vendor already does what you need, using it means no review, no procurement cycle, and no new contract.
</Step>
<Step title="What you'll use it for">
You get a short list of use cases this vendor is commonly bought for, rather than a blank box. Pick one, or type your own if none fit.
</Step>
<Step title="Which services are in scope">
A list of candidate services. You can add one that is not listed.
</Step>
<Step title="The inherent risk questionnaire">
Coverbase does most of this one for you. It answers what it can from public sources and whatever context you provided, then shows you each answer with the reasoning behind it.
Check them. Answers Coverbase was confident about are marked as such; the ones it was not are flagged for you to look at first. Anything about *your* intended use, the data you will send, or your internal owner is yours to answer, because public research cannot find it.
</Step>
</Steps>
Behind the scenes, Coverbase also screens the vendor's financial stability, security posture, and sanctions status, and checks whether the request duplicates something you already have. You do not have to ask for any of that. It runs as part of the flow, and you see the results.
<Note>
Which of these steps you see depends on how your organization configured its intake portal. Some orgs turn off web alternatives, or pre-qualification, or prior assessment history. If a step described here does not appear for you, your admin turned it off.
</Note>
## Getting through it faster
<AccordionGroup>
<Accordion title="Give context up front" icon="lightbulb">
Anything you already know: the use case, the data types involved, a link to their security page, the team that will own it. Coverbase feeds that into the drafting, so more context up front means fewer questions for you later.
</Accordion>
<Accordion title="Work the flagged answers first" icon="triangle-exclamation">
Drafted answers come with a confidence signal. The low-confidence ones usually name what was missing, and they are where your knowledge adds the most. The high-confidence ones mostly need a glance.
</Accordion>
<Accordion title="Finish it in one sitting if you can" icon="clock">
A partially answered request is not in anyone's queue. It sits open until you come back to it. If you do have to stop, you can pick it up later, in the portal or by asking the assistant where your request got to.
</Accordion>
<Accordion title="Do not guess on data questions" icon="shield-halved">
Questions about what customer data flows to the vendor drive the whole depth of the review. An optimistic answer here means a review scoped too shallow. If you do not know, say so.
</Accordion>
</AccordionGroup>
## After you submit
Your request lands in the risk team's review queue with everything attached: your answers, the enrichment, the screening results, and the duplicate check.
From there one of three things happens:
* **Approved.** Onboarding starts and an assessment is created against the right control set, sized to the risk your answers indicated.
* **Sent back.** A reviewer needs something clarified. You get a specific question rather than a rejection.
* **Rejected.** Usually because an approved vendor already covers the need, or the screening surfaced something disqualifying.
You cannot edit your answers after submitting. A reviewer can correct them on the way through, and can send the request back to you if something needs your input.
## Related
<CardGroup>
<Card title="Vendor intake in chat" icon="comments" href="/mcp/vendor-intake">
The full conversational flow, step by step, including what your assistant will and will not do on its own.
</Card>
<Card title="Analyst and reviewer guide" icon="user-check" href="/user-guides/analyst-reviewer">
What happens to your request on the other side, and what reviewers are looking for.
</Card>
</CardGroup>
# Reviews, approvals and gates
Source: https://docs.coverbase.com/user-guides/reviews-and-approvals
How review gates work in Coverbase: configurable outcomes including approve with finding, policy exception and return for rework; parallel domain-scoped SME reviews; multi-approver logic; and rework loops with reasons, comments and round counts.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is for admins and program owners designing the decision points in a third-party lifecycle. For who is allowed to press the button, see [Permissions and roles](/user-guides/permissions-and-roles). For who the button lands on, see [Assignment, delegation and out of office](/user-guides/assignment-and-delegation).
</Info>
A **review** is Coverbase's gate object. It is one accountable decision by one named party on one thing, and it carries the decision, the reason, the comment thread, and the round it happened on. Everything else in this guide is a way of arranging reviews: several in parallel, several in sequence, some conditional on an amount or a risk tier, and any of them able to send the work back.
## What every gate records
<CardGroup>
<Card title="Who" icon="user-check">
The assigned reviewer, and the user group they were drawn from when the gate was routed to a team rather than a person. Both are stored, so group intent and individual accountability survive together.
</Card>
<Card title="What" icon="circle-check">
The review's status, drawn from your organization's own review statuses under **Configuration → Statuses → Review**. A new organization starts with **Queued**, **Started**, **Accept** and **Reject**. A status in the completed group is the decision, and the review records when it was reached.
</Card>
<Card title="Why" icon="comment-dots">
The reviewer's own decision notes, the admin-authored instructions the gate was raised with, and, on a return for rework, the revision message that goes back to whoever owes the work.
</Card>
</CardGroup>
Reviews are first-class records. They appear in the audit trail, they raise `Review.Updated`, `WorkQueueItem.Created` and `WorkQueueItem.Completed` events you can subscribe to over [webhooks](/integrations/webhooks), they accept [custom fields](/api-reference/custom-fields), and they can be created and updated by a workflow as well as by a person.
## Gate outcomes are yours to define
Coverbase does not hard-code an approval vocabulary. **Configuration → Assessment Settings → Workflow → Approval Options** (choose **Edit approval options**) holds a list your organization owns, each option carrying a label, a color, and an icon. A new organization starts with two, and most regulated programs extend them.
| Shipped default | What regulated teams commonly add alongside it |
| - | - |
| **Approve** | **Conditionally approve**. **Approve with finding**: approved, with a tracked finding and an owner. **Approve with policy exception**: approved against standard, with the exception recorded, time-boxed and reportable. |
| **Reject** | **Return for rework**: not a rejection. The work goes back to the previous party with a reason and a comment, and the round count increments. |
<Tip>
Name outcomes the way your policy names them, not the way the software does. The outcome label is what appears on the vendor record, in exports, in board reporting, and in the filter menu, so "Approved with policy exception" reads correctly to an examiner in a way that "Conditionally approve" does not.
</Tip>
Options are archived rather than deleted, so an assessment closed two years ago under an outcome you have since retired still reports the outcome it was closed under.
### Outcomes drive what happens next
An outcome is not only a label on a record. The workflow engine can branch on it:
* **Assessment recommendation condition** matches the selected approval option against a set you choose, so `Approve with policy exception` can route to a different downstream path than `Approve`: raising an exception record, notifying the second line, and scheduling an earlier reassessment.
* **Review status** is stored on the review itself. A workflow triggered by a review update can act the moment a reviewer moves it to **Accept** or **Reject**, and the work queue items reviews create are what gating conditions read when several reviews have to agree.
See [Workflow engine](/integrations/workflow-engine#review-gates-and-approvals).
## Parallel domain-scoped reviews
A third party is rarely one risk. Coverbase models the split with **risk domains**, and a review can be scoped to exactly one of them.
An organization defines its own domains. A common financial-services set is Data Security, Operational Resilience, Regulatory & Compliance, Financial Stability, Privacy & Data Protection, Concentration & Fourth-Party Risk, AI & Emerging Technology, and Reputational & ESG. Rename them InfoSec, Finance, AML, Legal and Privacy if that is what your committees are called.
<Steps>
<Step title="Assign standing reviewers per domain">
Each risk domain carries its own reviewer list: individual users, user groups, or both. Assigning the AML group to the Financial Crime domain once means every AML review from then on routes there without anyone picking a name.
</Step>
<Step title="Issue the domain reviews together">
One assessment carries one review per domain, created at the same time. Each is a separate record with its own assignee, its own status, its own outcome, and its own notes. There is exactly one review per `(assessment, risk domain)` pair, so a domain cannot be reviewed twice by accident.
</Step>
<Step title="Each SME decides independently">
Every domain review mints its own work queue item for its own reviewer. InfoSec approving does not move Finance, and Legal returning its scope for rework does not reopen AML's decision. The reviews complete in whatever order the SMEs complete them.
</Step>
<Step title="Roll the domain outcomes up">
Domain scores and domain outcomes roll up to the assessment, the service, the engagement, and the vendor. Reporting can show the assessment-level answer and the per-domain answers that produced it.
</Step>
</Steps>
<Note>
Domain scoping runs the whole way down. Control sets can be sectioned by domain, the inherent-risk questionnaire can be sectioned by domain, findings can be assigned per domain, and Radar detectors can be tagged with the domains they inform. An SME who only owns Financial Crime sees the Financial Crime slice of the evidence, not the whole assessment.
</Note>
## Multi-approver logic
Any object that carries reviews can carry several at once. How they combine is a workflow decision, not a fixed rule.
<AccordionGroup>
<Accordion title="All of them must approve (unanimous)" icon="users-line">
Raise one review per approver, then gate the next step on a **work queue item complete** condition scoped to the workflow run with **require all** set. The gate stays shut until every review raised by that run is complete, whichever order they finish in.
</Accordion>
<Accordion title="Any one of them is enough (1 of M)" icon="user-check">
The same condition with **require all** turned off. The first completion opens the gate. Use it for a duty-officer rotation where anyone on the roster can clear a low-risk item.
</Accordion>
<Accordion title="N of M, and quorum by tier" icon="layer-group">
Express the quorum as the set of reviews you raise. A branch that raises three reviews and requires all three is a 3 of 3; a branch that raises only the two domains the intake implicated is a 2 of 8 against the full domain list. Because the conditions that decide which reviews get raised are evaluated per record, the quorum for a tier 1 vendor and a tier 4 vendor can differ without a second workflow.
</Accordion>
<Accordion title="Threshold and amount-based routing" icon="scale-balanced">
A **contract value** condition compares the total value of the active contracts on a procurement against a threshold you set, with `greater than` and `less than or equal` operators, so a request above your delegation-of-authority limit picks up the extra approver and one below it does not. The threshold is read in the contracts' own currency, and nothing is converted. When the valued contracts on a procurement are in more than one currency, the total cannot be compared with the threshold, so it counts as over it: `greater than` matches and `less than or equal` does not. A mixed-currency request therefore always picks up the extra approver.
Amount is one axis. Conditions can equally branch on inherent-risk score, vendor tier, data classification, hosting model, jurisdiction, questionnaire answers, tags, whether prior evidence exists, and any custom field, composed with `AND` / `OR` and nested.
</Accordion>
<Accordion title="Sequential approval chains" icon="arrow-right-arrow-left">
Chain gates by making each stage's trigger the previous stage's completion. Line one reviews, then the second line, then the committee. Each stage is a review in its own right with its own outcome, so a chain that stops at stage two shows exactly where it stopped and why.
</Accordion>
</AccordionGroup>
## Return for rework
Every review gate can send work back instead of ending it. A return for rework is a first-class transition, not a rejection with a different comment.
### What a return records
| Recorded | Where it lives |
| - | - |
| **Reason** | The outcome your organization selected, such as `Return for rework` or a narrower reason code like `Insufficient evidence` or `Missing DPA`. Because outcomes are your own list, the reason vocabulary is your own reason-code set. |
| **Comment** | A free-text revision message, written in the **Request revision** dialog. It is the text the counterparty reads, and it is stored on the round it was raised against. |
| **Who and when** | The reviewer who returned it and the timestamp, stamped automatically on the transition. |
| **Round** | The round number. Rounds auto-increment: the first submission is round 1, the response to the first return is round 2, and so on. |
### Rounds are the cycle count
Coverbase keeps every round rather than overwriting the last one. A returned item does not edit the previous submission; it opens a new round beside it.
```text theme={null}
Round 1 submitted 12 Mar reviewed 14 Mar Revision requested
"SOC 2 is for the parent entity, not the contracting entity.
Please provide the report covering Acme UK Ltd."
Round 2 submitted 21 Mar reviewed 22 Mar Revision requested
"Report received. Section 4 exceptions have no management response."
Round 3 submitted 28 Mar reviewed 28 Mar Accepted
```
Because the rounds are rows rather than edits, the cycle count is a number you can read, filter, sort and report on: how many rounds this assessment took, which control areas generate the most rework, which vendors take three rounds where their peers take one, and how long each round sat with each side. The counterparty-facing surfaces read the same rounds, so what the vendor sees and what your examiner sees are the same history.
### Where rework loops apply
<CardGroup>
<Card title="Questionnaire and evidence rounds" icon="clipboard-question">
A submitted questionnaire or evidence request can be returned to the vendor portal with a revision message. The portal reopens on the returned items only, and the vendor's completeness gate treats a returned round as outstanding work.
</Card>
<Card title="Remediation commitments" icon="handshake">
A vendor's completion evidence for a commitment can be pushed back with a message, returning the commitment to its prior state and reopening the portal. Coverbase can pre-draft that message from the evidence it read, but nothing goes back to the vendor until a person sends it.
</Card>
<Card title="Internal reviews" icon="user-clock">
A domain, contract, procurement, or assessment review can be set to a returned status with reviewer notes, which reopens the upstream work queue item rather than closing the gate.
</Card>
<Card title="Intake requests" icon="inbox">
An intake request that arrives incomplete goes back to the requester with what is missing, instead of being rejected and re-filed as a new request that loses its history.
</Card>
</CardGroup>
## Attribution and audit
Every transition above is attributable.
* The review stores its assignee, the group it was routed through, its creator, and the reviewer who decided it.
* Each round stores who submitted it, under which email address, who reviewed it, and when. A round that was amended after submission keeps the original submit time and records the edit separately.
* Group routing writes its own log row for each assignment: which group, which strategy, who was notified, who was assigned, and what triggered it.
* Role and permission changes that affect who could approve are logged on the role itself and in the organization audit trail.
All of it is readable through the [audit API](/security/audit-trails) and exportable.
## Related
<CardGroup>
<Card title="Assignment, delegation and out of office" icon="user-clock" href="/user-guides/assignment-and-delegation">
How a gate reaches a person, what happens when they are away, and how delegation is attributed.
</Card>
<Card title="Workflow engine" icon="gears" href="/integrations/workflow-engine">
The triggers, conditions and actions that raise gates and read their outcomes.
</Card>
<Card title="End-to-end workflows" icon="route" href="/integrations/end-to-end-workflows">
A worked parallel-review-and-approval lifecycle, with every API and webhook touchpoint.
</Card>
<Card title="Configuring your data model" icon="sliders" href="/user-guides/data-model-configuration">
Approval options, statuses, risk domains, custom fields and the rest, all self-serve.
</Card>
</CardGroup>
# Risk geography map
Source: https://docs.coverbase.com/user-guides/risk-geography-map
See where your suppliers are on a world map, narrowed by the same vendor filters you use on the vendor list.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For how supplier addresses get into Coverbase in the first place, see [Supplier information](/user-guides/supplier-information).
</Info>
The **Geography** tab under **Risk** draws every supplier location you hold. It answers a question per-vendor scoring does not: if forty of your suppliers run out of one metro area, one flood or one grid failure reaches all forty at once. You narrow the picture with the same filters you use on the vendor list.
<Frame>
<img alt="Risk geography world map with small dots for supplier sites in North America, Europe, Asia and Africa, tinted countries, and a Top exposure panel listing countries with counts" />
</Frame>
## What the map draws
The map draws three things, and they answer different questions.
### Site dots
A solid dot is a place where you hold a supplier address that Coverbase has geocoded. Sites that share the same coordinates draw as one dot, so a cluster of dots is several distinct places close together. The dots stay small at every zoom level: they say where a site is, not how many sit there. Read counts from the side panel or a hover.
### Country tint and hollow marks
Every country where you hold at least one location gets a faint tint, stronger where more suppliers sit, and you can click it. A tinted country with no dots holds only country-level records: suppliers where you recorded a country but no street address. When a country has nothing to place at all, a hollow dot sits at its center, and the side panel legend reads **Country recorded, no address to place**. The mark stays small, because a larger one would imply a precision the data does not have.
Hover a tinted country to see how many suppliers it holds and which ones. The count is exact, whether the addresses are placed or not.
<Frame>
<img alt="Country popover on the world map listing suppliers recorded in India with a Show more link" />
</Frame>
### The side panel
**Top exposure** ranks countries by supplier count, or world regions if you switch to **Region**. The line under it gives the totals for the current view, for example "94 vendors/services across 281 locations".
<Note>
A country-only supplier is a complete record. Plenty of suppliers have no single street address worth recording. The map keeps them visible rather than dropping them, so your country totals still include them.
</Note>
## Filtering the map
The **Filter** button sits at the top left of the map and opens the same filter menu as the **Vendors** and **Assessments** lists. Anything you can filter a vendor by, you can filter the map by.
<Frame>
<img alt="Filter menu open over the map listing Vendor, Tags, Archived, Risk Analysts, Status, and other vendor fields" />
</Frame>
Pick a field, pick a value, and the map redraws to the suppliers that match. Rules stack, and the bar under the button shows what is applied.
<Frame>
<img alt="Map with an active filter reading Inherent Risk Level is Critical, plus add and clear controls, and the side panel counts narrowed to the matching suppliers" />
</Frame>
Some things this makes easy:
| Question | Filter |
| - | - |
| Where are my critical suppliers? | **Inherent Risk Level** is your top band |
| Which regions does one analyst carry? | **Risk Analysts** is that person |
| Where is a single supplier? | **Vendor** is that supplier |
| Where do my payments-tagged suppliers sit? | **Tags** any of `Payments` |
Opening a location on a vendor's **Locations** card and choosing **View on the risk map** drops you here with that supplier already filtered and its country in focus. **View on map** on a vendor in the **Chain** tab does the same for that vendor. The rule is an ordinary one, so you can widen it, add to it, or clear it to get back to the whole estate.
### Archived suppliers
Archived suppliers are **off the map by default**. An archived supplier is one you have stopped working with, and leaving it in would inflate every country count you read.
To see them, add the **Archived** filter and set it to **Yes**. That reverses the default rather than adding to it, so you get archived suppliers only. It is a quick way to check what a wind-down removed from a region.
<Warning>
Archiving a supplier does not delete its addresses. They stay on the record, and they come back to the map as soon as the supplier is restored.
</Warning>
## Zooming into a country
Click any tinted country to zoom in. The side panel switches to that country's location count, its breakdown by state or province, and the suppliers there under **Vendors here**. The map swaps the world dots for one pin per place and outlines the states. Records with no state are counted as **Country-wide**, and addresses that could not be placed share a hollow pin at the country's center.
<Frame>
<img alt="Germany focused view with address pins near Frankfurt, a hollow pin at the center, and a side panel listing Hesse and Country-wide counts" />
</Frame>
Your choice is remembered on the device, so returning to the tab reopens on the same country. **Back to world view** in the side panel returns to the full map.
## Many suppliers at one address
Shared campuses, office towers and colocation facilities mean several suppliers often sit on exactly the same coordinates. Drawn one mark per supplier, they stack into a single dot and you only ever see whichever drew last.
Coverbase groups them instead. Zoom into the country, then hover the pin to see how many are there, with the site name and address for each.
<Frame>
<img alt="Popover on a New York pin reading 3 locations here, listing three suppliers with their site names and addresses" />
</Frame>
The list shows three, expands to ten with **Show more**, and then says how many remain. To see the rest, filter to the supplier or the owner you are chasing, and the same pin will show only those.
## What you need to see anything
<Steps>
<Step title="The Risk module is enabled">
**Geography** appears under **Risk**. If you have no **Risk** section, the module is not switched on for your workspace.
</Step>
<Step title="You can read vendors">
The map shows supplier names and links to their records, so it requires vendor read access. Someone without it will not be able to open the tab.
</Step>
<Step title="You hold some locations">
Addresses come from supplier site records. They are collected through questionnaires, added on the vendor's **Locations** card, or [loaded through the API](/api-reference/supplier-profile#sites). A workspace with no sites recorded gets an empty map.
</Step>
<Step title="Addresses have been geocoded">
Coverbase resolves addresses to coordinates on a schedule rather than when you save one, so a location added minutes ago counts toward its country first and gets its own pin shortly after. Until then, zooming into the country shows it in the hollow pin at the center.
</Step>
</Steps>
## What the map does not tell you
Check these before you present a number off this map.
### The map counts addresses, not headcount or spend
A supplier with one office and a supplier with thirty each contribute what they have recorded. The map answers where your suppliers are, not how much of your spend is there.
### A pale country is not an empty country
The tint is deliberately faint, and a country with few suppliers or only country-level records has few dots or none. Hover the country or read the side panel for the count.
### The counts follow your filters
Once a rule is applied, every number in the side panel and every popover describes the filtered set, not the whole estate. Clear the filter before reading a total.
## Related
<CardGroup>
<Card title="Supplier information" icon="building-columns" href="/user-guides/supplier-information">
How addresses and other supplier records are collected and validated.
</Card>
<Card title="Filter fields" icon="filter" href="/fields/overview">
Every field you can filter on, and what the operators mean.
</Card>
</CardGroup>
# Risk methodology
Source: https://docs.coverbase.com/user-guides/risk-methodology
Configure the Risk Methodology page: domain weights and Risk Groups, how domain scores roll up, the reviewer matrix, SLA escalation rules, inherent risk questionnaire versions and review cadence, score overrides with a rationale and expiry, and how far residual risk can fall below inherent risk.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Configuration → Risk Methodology** and the score editor's override fields. It sits beside [Configuring your data model](/user-guides/data-model-configuration), where risk domains and scales are created, and [The IRQ library](/user-guides/irq-library), where inherent risk questionnaires start. For what the module is, see [Risk methodology](/products/risk-methodology).
</Info>
The **Risk Methodology** page is one place for the rules inherent risk follows: how domains roll up, who reviews what, when overdue work escalates, and which questionnaire version is live. It has five tabs: **Risk Domains**, **Tiers, Scales & Cadence**, **Reviewer Matrix**, **SLAs & Escalation** and **IRQ Versions**.
Your Coverbase representative turns on the third-party lifecycle features for your organization.
The mistake people make most often is changing the aggregation method and expecting existing vendors to be re-rated. The method applies to questionnaires scored from then on. Scores already recorded stay as they are until the questionnaire is scored again.
Open **Configuration** and choose **Risk Methodology**. Changing settings needs a role that can change organization settings.
## Step 1: Weight your domains
The **Risk Domains** tab lists each domain with its **Weight**, its share of the roll-up, and its **Risk Group** (its reviewers). A domain with no weight reads **Not weighted** and is left out of the weighted roll-up. Click **Edit risk domains** to change them on the risk domains page.
* Leave every weight empty to keep the questionnaire's flat score. Weighting turns on only when at least one active domain has a weight.
* Weights are relative. They do not need to add up to 100, because the score is normalized by the weights of the domains that scored.
* A questionnaire section must name a risk domain for its answers to count toward that domain. Answers in sections without a domain, or in a domain without a weight, are counted and shown on the review as unweighted answers.
## Step 2: Choose how ratings roll up
On **Tiers, Scales & Cadence**, under **How Ratings Roll Up**, choose one:
| Method | Overall rating |
| - | - |
| **Weighted average only** | The weighted mean of the domains, or of every answer when no domain carries a weight. The default. |
| **Highest domain wins** | The worst domain's score. |
| **Weighted average with a domain floor** | The weighted mean, but never below one tier under the worst domain. A Critical domain makes the overall rating at least High. |
<Frame>
<img alt="How Ratings Roll Up card offering Weighted average with a domain floor, Highest domain wins and Weighted average only, with Weighted average only selected" />
</Frame>
The change saves at once. An answer option with a minimum score still lifts the whole questionnaire afterwards, whichever method you choose.
**Scale Normalization** shows how each domain's scoring scale maps onto your 0 to 100 risk bands, so a three-tier and a five-tier scale read side by side. Select a domain to see each level's **Normalized Score**, and use the preview to see the residual risk a given assessment score leaves at a given inherent risk.
**Monitoring Cadence by Tier** shows how often each monitoring activity runs at each tier. **Edit cadence** changes it; see [Monitoring plans](/user-guides/monitoring-plans#step-1-set-the-methodology).
## Step 3: Route reviews with the reviewer matrix
On **Reviewer Matrix**, click **Add rule** and fill in the **Add Reviewer Rule** dialog:
| Field | Matches |
| - | - |
| **Requesting Group** | The user group of the person who asked for the vendor. |
| **Business Unit** | The engagement's business unit, when there is an engagement. |
| **Tier** | The inherent risk tier. |
| **Risk Domain** | The domain being reviewed. |
| **Reviewer** | The user or group who reviews when the rule matches. |
Leave a criterion on **Any** to match everything. The most specific matching rule wins, and the table lists rules in the order routing checks them: most specific first, then oldest first. A rule with exactly the same criteria as another is refused. With no rule matching, reviews go to the domain's own reviewers and the portal defaults.
<Frame>
<img alt="Reviewer Matrix table with rules by requesting group, business unit, tier and risk domain, the most specific rule (Beauty, Critical, Privacy & Data Protection) first" />
</Frame>
Intake review is routed before a tier is known, so only rules with no **Tier** and no **Risk Domain** apply to intake. When an IRQ is approved, every domain it scored gets a review task, routed by these rules.
## Step 4: Escalate overdue work
On **SLAs & Escalation**, **SLA Targets** lists how long each stage of an assessment may take before it is overdue: the **Organization default**, and any risk domain that overrides it. **Edit SLA targets** changes them. These targets drive the engagement's expected decision date.
Under **Escalation Rules**, click **Add rule** and fill in the **Add Escalation Rule** dialog:
1. **Name** the rule, for example "Overdue Risk Group review".
2. Choose the **Work** it applies to. Leave it empty to escalate every kind of work.
3. Set **Days Overdue**.
4. Choose who it escalates to: a **User**, a **Group**, or a **Group lead** (the group's lead at the time the item escalates).
5. Choose **Notify**, so the target gets their own copy and the assignee keeps the item, or **Reassign**, so the item moves to the target.
Escalation runs once a day. Each rule escalates an item once. A copy closes when the original's record resolves, and never escalates again itself. The **Escalation Log** lists every item a rule escalated, newest first, with the rule, when, who it went to and how overdue it was; filter it by rule.
## Step 5: Version your inherent risk questionnaires
**IRQ Versions** lists each inherent risk questionnaire with its **Version**, **Published** date and **Content Review Due**. Use the row's actions to **Open template** or **View changelog**: every change across all of its versions.
<Steps>
<Step title="Draft">
Click **Draft next version**. The draft copies the published version and is not sent to anyone.
</Step>
<Step title="Edit">
Open the draft and change its questions. Drafting, edits, publishing, retiring, content reviews and cadence changes are recorded in the changelog with the version and who acted.
</Step>
<Step title="Publish">
Click **Publish** and confirm. The draft becomes the published version, and the previous version is retired for new sends. Questionnaires already out finish on the version they were sent with.
</Step>
<Step title="Set a review cadence">
Click **Review cadence**, choose **Review Every** (in months) and an **Owner**. The owner is reminded when the published version is due for review. **Mark reviewed** restarts the clock.
</Step>
</Steps>
A published or retired version is read-only: its questions, sections, options and conditions cannot change, and the editor's banner offers **Draft new version** instead. The name, reviewers and applicability stay editable. To see what changed between two versions, use **Compare** (below).
### Compare two versions
From a version's actions, choose **Compare with previous version** or **Compare with published**, or **Compare** to pick any two. The page shows both side by side: **Sections** and **Questions** **Added**, **Removed** or **Changed**, with answer options, weights, risk domains, answer types and review flags. **Swap versions** reverses them, and **Show unchanged questions** shows everything.
### Retire versions
Select versions and choose **Retire**, or use **Discard draft** on one draft. A retired draft can no longer be published. Retiring the published version stops new sends of that questionnaire until a new version is published; questionnaires already sent finish on their version.
## Step 6: Override a score with a rationale
Anywhere you edit an inherent or residual score by hand (**Edit Inherent Risk Score**, **Edit Residual Risk Score** or **Edit Assessment Score**), the editor asks for a **Rationale**, recorded with the override in the score history, and **Override Expires**: **Never**, or **After 30 days**, **90**, **180** or **365**. The rationale is required. With an expiry, the editor says when the calculated score returns.
While it is active, a chip beside the score reads **Override ends in N days** (or **Override ends today**). When an override expires, a daily job restores the last calculated score for each risk type the override changed, and the risk profile shows **Override expired**. If someone or something has replaced the override in the meantime, the newer score stands.
## Set how far residual risk can fall
Residual risk starts from the formula under **Configuration → Scoring → Risk Scoring → Residual Risk Formula**: inherent risk reduced by the assessment score, weighted by **Assessment score weight**. **Residual Risk Step Down** then decides how far below inherent risk the result may land.
* **No limit**: residual risk follows the formula, however many levels it drops.
* **Cap the step down**: the formula still sets the score, but residual risk lands at most **Most Levels Below Inherent** levels below inherent risk. With a one level cap, Critical inherent risk ends no better than High.
* **Set by rating**: residual risk lands exactly one level below inherent when the assessment's rating is one you tick under **Ratings That Step Down One Level**, and stays at inherent for any other rating. A qualifying rating moves residual risk one level down even when the formula would have left it at inherent. Inherent risk already at your lowest level stays there.
**Set by rating** reads your assessment rating scale (the **Assessment Scoring** tab), so set that scale up first. The rating is the band the assessment score falls in. The overall residual uses the overall rating, and each risk domain uses its own domain rating. While the rule uses a rating, that rating cannot be removed from the scale, and the scale cannot be turned off. Choose another step down first.
A change applies the next time an assessment's residual risk is calculated. Completed assessments and current vendor scores keep their values. When the rule moves a score, the assessment's **Summary** tab shows the score the formula gave, the level the rule set, and under **Set by rating** the rating that decided it. Significant deficiency floors still apply on top, and the higher of the two wins.
## Try a what-if
* On a submitted inherent risk questionnaire, **Inherent Risk What-If** lets you change answers and shows where each domain and the overall rating would land, for example "With 2 changed answers, inherent risk moves from High 72 to Medium 48". **Reset** puts the answers back. Nothing is saved; the respondent's answers are unchanged.
* On an assessment's summary, **Residual Risk What-If** lists the open issues. Turn on **Remediate** for the ones to fix and read the **Domain Change** and **Overall Change**, for example "Remediating ISS-311 drops Privacy residual risk from High 61 to Medium 44". A significant deficiency floor stays in force, so a floored score may not move until the deficiency itself is resolved.
## Reading an IRQ result
<Frame>
<img alt="Why This Rating card with the top three answers and how much each added, above the Inherent Risk What-If with an answer picker for each question" />
</Frame>
On a submitted inherent risk questionnaire, **Why This Rating** explains the score: the answers that moved it most, whether the highest domain rated it (**Rated by the highest domain**) or a floor lifted it (**lifted to ... by the ... floor**), and any answers flagged for review. Answer options can be flagged so the reviewer's attention goes to them.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| The weighted score ignores a section | The section has no risk domain, or its domain has no weight. | Give the section a domain and the domain a weight. The review's unweighted count shows how many answers this affects. |
| Changing the aggregation method did not change a vendor's rating | The method applies to questionnaires scored after the change. | Score the questionnaire again, or send a new one. |
| A reviewer rule does not apply to intake review | The rule names a **Tier** or a **Risk Domain**. | Add a rule with neither for intake. |
| Reviews still go to the domain's reviewers | No rule matches the request's group, business unit, tier and domain. | Widen a criterion to **Any**. |
| An overdue item was not escalated a second time | Each rule escalates an item once. | Add a second rule with a larger **Days Overdue**. |
| Editing a question fails with a message that the version is locked | The version is published or retired. | Click **Draft new version** and edit the draft. |
| Saving a score override fails | The **Rationale** is empty. | Write a rationale. |
| A score went back to an older value on its own | An override with an expiry lapsed. | Expected. Override again with a rationale if the calculated score is still wrong. |
## Related
<CardGroup>
<Card title="Configuring your data model" icon="table-columns" href="/user-guides/data-model-configuration">
Risk domains, scales and statuses.
</Card>
<Card title="The IRQ library" icon="clipboard-list" href="/user-guides/irq-library">
The packaged inherent risk questionnaires.
</Card>
<Card title="Front Door triage" icon="door-open" href="/user-guides/front-door-triage">
IRQ scoping rules on intake.
</Card>
<Card title="Reviews, approvals and gates" icon="gavel" href="/user-guides/reviews-and-approvals">
Domain-scoped reviews on an assessment.
</Card>
</CardGroup>
# The Risk module: register, signals and scenarios
Source: https://docs.coverbase.com/user-guides/risk-register
How to keep a risk register in Coverbase: score a risk on the 5x5, let findings, contracts and Radar feed it as signals, decide on what the agent proposes, trace the dependency chain, run a what-if scenario, and produce the board pack.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Risk** entry in the left navigation: the register, the chain, scenarios, exposure and the board report. The **Geography** tab has its own guide, [Risk geography map](/user-guides/risk-geography-map). Vendor-level risk scores and how services roll up into them are in the [Admin and setup guide](/user-guides/admin-setup#step-5-configure-risk-and-compliance-scales).
</Info>
<Note>
Risk is an optional module. If you do not see **Risk** in the left navigation, ask your Coverbase representative to turn it on.
</Note>
The register is a list of statements about what could hurt your organization, each scored on a 5x5 of likelihood and impact. It does not hold evidence of its own. A risk points at records in the other modules (an open finding, a contract without a DPA, a Radar alert, a sanctions match) through **signals**, and those signals open and close as the source record changes.
An agent reads the same modules, proposes risks and re-scores, and files stale ones for review. It never closes or deletes a risk on its own. Everything it wants changed waits in an inbox for a person.
The mistake to avoid: leaving the residual score empty. An unscored residual falls back to the inherent score, so a risk you have treated keeps reading **Outside appetite** until you score the residual likelihood and impact.
## Where it lives
Click **Risk** in the left navigation. Six tabs run across the top, in the order a risk officer reads them:
| Tab | What it answers |
| - | - |
| **Register** | What could hurt us, who owns it, and is it inside appetite |
| **Chain** | What passes through what: business units, services, vendors, fourth parties, regions |
| **Simulate** | What happens if a vendor goes down, a process changes, or we offboard someone |
| **Exposure** | Are we inside appetite per domain, what is the probable loss, and where are we concentrated |
| **Report** | What the board sees this quarter |
| **Geography** | Where suppliers sit on the map (see the [geography guide](/user-guides/risk-geography-map)) |
Two buttons sit to the right of the tabs. **Ask the register** opens a question box that answers from the register, the chain and the signals, and cites the records it used. **Configuration** opens **Configuration → Risk**, covered [below](#configuring-the-module).
## Reading the register
<Frame>
<img alt="Risk register with summary tiles, a filterable table of risks and a side panel" />
</Frame>
The five tiles at the top are filters. Click **Outside appetite**, **Unowned** or **Reviews overdue** to narrow the table to those risks; click again to clear. **Proposed by agent** opens the [agent inbox](#deciding-on-what-the-agent-proposes). **Open signals** shows the count and the change since the last run.
The line under the filters reads, for example, "12 risks · 3 proposed hidden · sorted by residual, highest first". Proposed risks never appear in the table; they wait in the inbox.
| Column | What it shows |
| - | - |
| **Risk** | The `R-XXXX` label, the statement, and the scope (vendors, services, business units, regions) |
| **Domain** | The risk domain, or none |
| **Owner** | A person or a department. **Unowned** if neither. An accepted risk shows "accepted risk · until date"; a risk with a commitment shows its state and due date |
| **Signals** | Open and closed signal counts, with an icon per source module |
| **Inh** | Inherent score: likelihood x impact before treatment, 1 to 25 |
| **Res** | Residual score after treatment. Equals the inherent score while the residual is unscored |
| **Appetite** | **Outside**, **Near**, **Inside** or **Unscored**, evaluated against the domain's tolerance |
| **Review** | The next review date, flagged **Review overdue** once it passes |
Appetite is read from the domain's **Max Residual** (default 12). A residual above it is **Outside**, a residual within two points of it is **Near**, and anything lower is **Inside**. A risk without a domain uses the default and rolls up as "No domain".
The filter bar narrows by domain, owner, institution, signal source, status scope (**Active risks**, **Closed risks**, **All risks**) and free text, and sorts by residual, inherent, review date or last updated. **Matrix** switches the table to the 5x5 heat map, with inherent and residual dots and the tolerance line drawn on it. Every filter is in the URL, so a filtered view is a link you can send.
The side panel lists **By Risk Domain** (count and how many are outside appetite) and **Where Risks Come From** (signals per source module). Clicking a row filters the table. Underneath, the panel shows when the agent last ran and what it did, with a **Run agent now** button.
### Statuses
| Status | Meaning |
| - | - |
| **Proposed** | Filed by the agent and waiting in the inbox. Not in the table, not in the scores |
| **Open** | Accepted or created, no treatment under way |
| **Mitigating** | A commitment has been requested from the owner |
| **Accepted** | The organization carries the risk as scored. Set by **Accept risk** |
| **Closed** | Treated or no longer relevant. Set from a stale proposal (**Close as treated**) or by a workflow action |
Archiving is separate from closing. **Archive** removes the risk from the register and its scores. Its signals stay on their source records.
## Creating a risk
<Steps>
<Step title="Open the form">
Click **New risk** in the filter bar. From a vendor, service, contract or finding page, the **Risks** card has **Add risk**, which opens the same form with that record already in scope.
</Step>
<Step title="Write the statement">
**Statement** is what a board reader sees. The placeholder asks the right question: what could hurt the organization, and how?
</Step>
<Step title="Classify and assign">
Pick a **Risk Domain** (its appetite decides the tolerance), a **Category**, an **Owner** (a person or a department) and, if your org has institutions, an **Institution** or **Group**.
</Step>
<Step title="Score it">
Pick **Likelihood** and **Impact** from your org's five levels; the inherent score updates as you choose. Then pick **Residual Likelihood** and **Residual Impact** for the position after treatment. Leave them at **Unscored** only if you have not treated the risk yet.
</Step>
<Step title="Treatment and scope">
Choose a **Treatment** (**No treatment**, **Mitigate**, **Accept**, **Transfer**, **Avoid**), a **Review Date**, and write the **Treatment Plan**: what is being done, by whom, and the residual target. Add the vendors in scope. Click **Create risk**.
</Step>
</Steps>
When you edit a risk later, the same form adds a **Note** field. Whatever you write there is recorded in the risk's history alongside the change.
## Working a risk record
Click a row to open the record. The URL becomes `/risk/register/<id>`, so it is a link too.
<Frame>
<img alt="Risk detail drawer showing scoring, treatment, chain, signals and history" />
</Frame>
The header carries **Simulate** (opens the Simulate tab with this statement as the question and runs it), **History**, **Edit**, and **Archive**. Below it, the appetite pill, the status pill and where the risk came from: "Agent-created · accepted by name, date" or "Created by name, date".
**Scoring** shows the inherent and residual lines as likelihood x impact and the domain tolerance they are read against. **Treatment** shows the chosen treatment, the plan and the residual target.
**Owner** carries the actions that move a risk:
| Action | What it does |
| - | - |
| **Request commitment** | Asks the owner to commit to treating the risk by a date. Coverbase creates a finding with the risk as its source and a commitment assigned to the owner, attaches it to the risk as a **Commitment** signal, and moves an **Open** risk to **Mitigating**. If the risk is unowned, the request goes to the domain owner |
| **Add treatment task** | Opens the edit form on the treatment, plan and review date |
| **Accept risk instead** | Asks you to confirm, then sets the treatment to **Accept** and the status to **Accepted**. Accepting records that the organization carries the risk as scored |
| **Set review date** | The risk reappears in the **Reviews overdue** tile when this date passes without a review |
**In the Chain** shows how many business units and customer channels sit behind the risk's vendor, with **Open in Chain**. A risk not tied to a chain node says so.
**Agent rationale** appears on agent-created risks and on any risk the agent re-scored. **Explain more** expands it. If the agent applied a re-score, **Undo** restores the previous levels and journals the reversal.
### Signals on a risk
**Signals** lists every attached record with its source icon, its severity, and its status. A status that changed since attachment reads "from → to". A signal that closed says **Closed**, a dismissed one **Dismissed**, and one whose source was archived **Source removed**. Nothing is ever deleted from this list, so a finding that was open when the risk was raised still shows on the timeline after it resolves.
* **Attach signal** opens evidence the agent found in other modules but did not attach. Attaching keeps a reference, never a copy. **Suggest more** asks the agent to look again.
* The **x** on a signal dismisses it. The source record is untouched.
**History** is the append-only journal: created, proposed, accepted, dismissed, re-scored, owner, status or treatment changed, signal attached, closed or dismissed, merged, edited, scale remapped, closed, reopened. Each row names the person or the agent and shows the scores after the change.
## Signal sources and thresholds
A signal is attached only when its source is enabled under **Configuration → Risk → Signal Sources** and the record clears the threshold set there. Every source is on by default except **Assessments**.
| Source | Becomes a signal when | Closes when |
| - | - | - |
| **Findings** | An open finding at or above **Min severity** (default High), or any open finding with a missed remediation commitment | The finding is resolved or archived |
| **Commitments** | A commitment misses its due date. This also raises a re-score suggestion (likelihood up one step) | The commitment is met |
| **Contracts** | An active contract renewing within the window (60 days) on a vendor with open findings | The contract stops being active |
| **Contract clauses** | A clause match reviewed as non-conforming or accepted risk | The match leaves an open status |
| **Contract component gaps** | A DPA, SLA, security addendum, SCC, subprocessor list or AI addendum slot is missing or expired on an active contract | The slot is present or not required |
| **Obligations** | Not satisfied past its due date, or pending acknowledgement older than **Days** (14) | Satisfied or archived |
| **Screening** | An unresolved or confirmed sanctions, PEP or adverse media match | Reviewed as not a match |
| **Radar signals** and **Radar alerts** | At or above **Min severity** (any severity for signals, High for alerts). An alert counts once a reassessment has cited it | Resolved, dismissed or archived |
| **Vendor risk changes** | A vendor score rose within the last 30 days | The change is older than 30 days |
| **Inspect** | An evaluation marked as an issue in the latest run | No longer an issue |
| **Assessments** (off by default) | An SLA breach, or a domain residual above the domain's appetite | Neither holds |
| **Supplier sites** | An active site in a sanctioned country, or in the EU/EEA/UK while a DPA slot on the vendor's contracts is missing or expired | The site is retired or a DPA appears |
| **Chain single points of failure** | A node several services or business units depend on, with no recorded alternative | The node gains an alternative or leaves the chain |
| **Financial health** | The vendor's financial health score fell by **Min score drop** (15) since the previous reading, or a submitted statement failed validation | The latest score is no longer a drop |
Turning a source off stops new attachments. It never removes signals already on a risk. Signal statuses refresh when the source module changes and again in a nightly pass.
## The agent
The agent runs every night, about five minutes after a qualifying change in another module, and whenever someone clicks **Run agent now** (on the register side panel or under **Configuration → Risk → Agent**). One pass refreshes signal statuses, scans the sources, attaches new evidence to the open risk on the same vendor and category (or proposes a new risk), suggests re-scores, and flags stale risks.
Two settings under **Agent** decide how much it does on its own:
* **New risks**: **Propose for review** (default) files each new risk as **Proposed** for a person to accept. **Create directly** opens them as **Open** risks.
* **Re-scoring**: **Suggest** files a re-score suggestion. **Apply and notify** writes the new levels and journals the change; you can still **Undo** on the record.
**Stale after** (default 120 days without a signal change) and free-text **Instructions** (for example, "treat any vendor with access to the core ledger as Tier 1") complete the settings.
<Warning>
The agent never closes, archives or deletes a risk. When every vendor in scope is retired, or every signal has closed, it files a stale proposal with a suggested close. A person applies it or keeps the risk open. A risk you edited or dismissed is never re-proposed by a later scan.
</Warning>
### Deciding on what the agent proposes
Click the **Proposed by agent** tile. The inbox has four tabs.
<Frame>
<img alt="Agent inbox listing proposed risks with Accept, Edit and accept, Merge into and Dismiss buttons" />
</Frame>
| Tab | Decisions |
| - | - |
| **Proposed** | **Accept** opens the risk as scored. **Edit and accept** opens the form first. **Merge into…** folds it into a similar existing risk, moving its signals and scope across. **Dismiss** archives it |
| **Re-score suggestions** | **Apply** writes the suggested levels and journals a re-score. **Keep current** dismisses the suggestion |
| **Merge suggestions** | **Merge** or **Keep separate** |
| **Stale** | **Close as treated** closes the risk. **Set review date** keeps it open with a new date (90 days out unless you pick one). **Keep open** dismisses the flag |
**Dismiss** asks why: **Not a risk for us**, **Duplicate**, **Wrong scoring**, **Already treated** or **Other**. The reason is fed back to the agent and recorded in history.
Each card shows the agent's confidence, its rationale under **Why**, and the signals under **Evidence**. A proposal the agent files with no signals of its own still cites the records it read.
## Chain
<Frame>
<img alt="Dependency chain graph with columns for business units, services, vendors and fourth parties" />
</Frame>
The chain is rebuilt nightly from business unit dependencies, services, active contracts, each vendor's fourth parties (subprocessor lists where there is no entity), supplier sites and vendor risk profiles. The header names the snapshot and its date, so a scenario always says which chain it ran on.
**Follow** picks which chain the graph traces:
| Mode | Shows | Ordered by |
| - | - | - |
| **Data** | Data scopes each vendor handles; locations hidden. A dashed edge carries customer data | Build order |
| **Money** | The same chain without data scopes or locations | Annual contract value, so the largest vendors survive the node cap |
| **Operations** | Regions and sites vendors operate from | The criticality recorded on each business unit dependency |
Narrow with **Data scope**, **Business unit**, **Depth** and **Show only critical paths**. A column with too many nodes collapses the rest behind **+N more**; **Show all** expands it. In the legend, a red edge has no contractual protection, a ring marks a node with an open register risk, and a red node is a single point of failure.
Click a node to see what it depends on, what it serves, its contract (liability cap, SLA, DPA in place or not), and what is open against it (findings, obligations). **Simulate outage** runs an event scenario on it. **Single points** lists every single point of failure by reach, with how many alternatives are on record.
## Simulate
<Frame>
<img alt="Simulate tab with the scenario builder showing Event, Subject, Duration and Starts fields and the Or ask box" />
</Frame>
Pick a **Scenario kind**:
* **Event**: an **Outage**, **Breach**, **Insolvency**, **Sanction** or **Market exit** on a **Subject** from the chain, for a **Duration**, starting in **Business hours, weekday**, **Overnight** or **Weekend**.
* **Change**: **Describe the change** in a sentence and name the **Vendors involved** and **Business units involved**. The result lists what it touches: control sets, register risks, obligations and open questions for stakeholders.
* **Offboard**: a **Vendor to offboard**. The result is a brief: termination terms on file, dependencies, open findings and obligations, and alternatives.
Or type the question under **Or ask** ("What if Cloudflare is down for a working day?") and click **Ask**. The form adopts the inputs the model understood, so you can adjust and re-run.
<Note>
The engine never fills in a number you have not recorded. If an estimate needs an input the org does not hold (a liability cap, a business unit's revenue), the loss reads **Estimate withheld** with the reason, and **Improve it** lists what to record. Confidence is derived from how many inputs are present, never asserted.
</Note>
A result shows services down, items touched, business units and customer channels, obligations triggered (regulatory and contractual), open findings on the path, the estimated loss, contractual protection per contract, and the **Blast radius** table: each business unit, the services affected, whether the channel is customer-facing, whether a workaround is on file, and the owner.
Under the result: **Save scenario**, **Attach to risk** (the scenario is recorded against that risk and listed as attached to it under **Saved scenarios**), **Create risks from gaps** (each selected draft becomes a proposed risk with the scenario as its first signal) and **Export brief** (a Markdown file). **Saved scenarios** reopens any earlier run with its result.
## Exposure
<Frame>
<img alt="Exposure tab with appetite gauges per domain, a loss exceedance curve, a cushion table and concentration bars" />
</Frame>
* **Appetite by domain**: one gauge per domain plus "No domain", with the count outside appetite, the appetite statement, the average residual and a 90-day trend (**rising**, **flat**, **falling**). Click **N outside** to open those risks in the register.
* **Probable annual loss**: the loss curve with the appetite line, the **Method** chip (change it under **Configuration → Risk → Quantification**), **Inputs present** per input type, the confidence, and **Vendors without inputs**. Only vendors with a residual score and a sized exposure are modeled; the rest are named, not defaulted.
* **Cushion analysis**: per contract, the ACV, liability cap, insurance (**none on file** or **not extracted**) and the unprotected amount. **Extract from contract** runs clause extraction on rows missing a cap. Unknown stays unknown.
* **Concentration**: shared fourth parties, business units on one vendor, and geography, each linking into the chain.
The line at the bottom names how fresh the assessments, contracts and Radar data are. **Institution** switches between **Group** and one institution.
## Report
<Frame>
<img alt="Report tab showing KRI tiles, movers this period, appetite breaches and a domain table" />
</Frame>
Choose a **Period** (the last six quarters). Four tiles carry a six-quarter sparkline: **Risks outside appetite**, **Avg residual · Tier 1 vendors**, **Commitments on time** and **Framework coverage** (against the frameworks chosen in configuration). **Movers this period** lists re-scored, new and closed risks; **Appetite breaches** lists the domains over their **Max Outside**; **KRIs by domain** gives each domain its owner, risk count, outside count, residual trend, open signals and top risk. All of it is read from the journal, so a re-score that later reversed still shows as a move in its period.
**Narrative** drafts the board text from the register, the chain and the period's signals. It is marked "drafted · edit before export"; click **Edit**, change it, **Save**. Every number in it traces to a risk or signal. **Pinned Chart** shows one chart from an org dashboard (see the [Dashboard library](/user-guides/dashboard-library)); the PDF names it but cannot embed the live view.
**Export board pack** builds the PDF in your browser. **Schedule** emails the report **monthly** or **quarterly** on a chosen day to the recipients you list, for one institution or the whole group. The same schedule is editable under **Configuration → Risk → Board Pack Schedule**.
## Configuring the module
Open **Configuration → Risk**, or click **Configuration** on the Risk page. Each section saves on its own.
| Section | What it holds |
| - | - |
| **Taxonomy & Domains** | Your risk domains with their owner, control sets, Coverbase category mapping and whether an appetite is set. **Manage domains** opens **Configuration → Risk Domains**, where domains, their reviewers and their control sets are created |
| **Scales & Matrix** | Five levels per axis with a label and criteria, and a preview of the 25-cell matrix |
| **Appetite Statements** | Per domain: a **Statement** in your words, **Max Residual** (the tolerance, default 12) and **Max Outside** (how many risks over it the domain tolerates before it breaches). **Portfolio Thresholds** are the numeric tolerances the quantification model checks |
| **Quantification** | The method behind **Probable annual loss** and its parameters. Switching method resets the parameters to that method's defaults |
| **Signal Sources** | The on/off switch and threshold per source ([above](#signal-sources-and-thresholds)) |
| **Agent** | **New risks**, **Re-scoring**, **Stale after**, **Instructions** and **Run agent now** |
| **Institutions** | A **Key** and **Label** per institution. A holding company sees **Group**; each institution sees its own rows. A risk is scoped to one institution or shared |
| **Frameworks** | The frameworks the board pack reports coverage against |
| **Board Pack Schedule** | The scheduled send: cadence, day of month, institution, recipients |
<Warning>
Editing a scale re-maps existing risks by level **name**; it never re-scores them. A label you move from level 2 to level 3 takes its risks with it, and a name you remove leaves its risks at their number. Each moved risk gets a history row recording the remap.
</Warning>
<Frame>
<img alt="Risk configuration Signal Sources section with a toggle and threshold per source" />
</Frame>
The 5x5 here is not the vendor risk scale. Vendor and service scores (0 to 100, with bands and service roll-up) are configured under **Configuration → Scales** and described in the [Admin and setup guide](/user-guides/admin-setup#step-5-configure-risk-and-compliance-scales). A vendor score that rises reaches the register as a **Vendor risk change** signal.
## How the other modules connect
Vendor, service, contract and finding pages each carry a **Risks** card listing the register entries scoped to that record, with their residual score and appetite state, **Add risk**, and **View in register**, which opens the register filtered to that record ("Scoped to this vendor"). Proposed risks show as **Proposed by agent** on the card. An intake request for a vendor you already hold shows the same card, as **Open risks on this vendor**, beside the intake questionnaire until the request is submitted.
The reverse direction is the signal table above: [findings](/products/findings-manager) and their commitments, [Radar](/products/supplier-radar) signals and alerts, [contract components](/user-guides/contract-components) and clause reviews, obligations, [sanctions screening](/user-guides/sanctions-screening), the [financial health score](/user-guides/financial-health-score), [supplier sites](/user-guides/supplier-information), Inspect evaluations and assessments all reach the register as signals on the risks that cover them. Charts on your dashboards can slice the register by domain, status, appetite, owner and institution. Workflow automations have **Create risk** and **Update risk** actions (see [Workflow templates](/user-guides/workflow-templates)).
A risk that needs a person (a proposal, an overdue review, or an unowned risk outside appetite) also appears once in the work queue, assigned to its owner, or failing that the owning department's lead or a domain reviewer.
## Who can do what
Risk has its own permission resource, **Risk register**, with these grants. Members hold them by default; a missing button means the grant is missing from your role.
| Grant | What it allows |
| - | - |
| Read | Every tab, the record, and viewing the configuration page |
| Create | **New risk**, **Add risk**, **Create risks from gaps**, saving a scenario |
| Update | **Edit**, **Accept risk**, **Request commitment**, **Set review date**, attaching or dismissing a signal, every inbox decision, **Attach to risk**, editing the narrative |
| Archive | **Archive** on a risk, deleting a saved scenario |
| Run | **Run agent now**, running a scenario |
| Export | **Export board pack** |
Saving anything under **Configuration → Risk** needs the organization settings permission, which Admins hold. Roles are managed as described in [Permissions and roles](/user-guides/permissions-and-roles).
## Notifications
Two notification types live under the **Risk** category in your personal notification settings. Both group one agent run's output into a single email.
| Notification | Sent when | Sent to |
| - | - | - |
| **Risk proposal awaiting review** | The agent proposes a new risk, a re-score, a merge or a stale review | The domain's reviewers, the lead of each reviewing department, and the risk's owner |
| **Risk outside appetite** | A risk is re-scored above its domain's tolerance | The risk's owner, the owning department's lead, and the domain's reviewers |
Each email carries a button that opens the risk. Delivery settings are covered in [Email and notifications](/user-guides/email-notifications#who-receives-what).
## Troubleshooting
| What you see | What is happening |
| - | - |
| A treated risk still reads **Outside appetite**. | Its residual is unscored, so it falls back to the inherent score. Edit the risk and set **Residual Likelihood** and **Residual Impact**. |
| The count line says "3 proposed hidden" but the table shows nothing new. | Proposals never enter the table. Click the **Proposed by agent** tile to decide on them. |
| A finding I expect is not a signal. | Its severity is below **Min severity** for **Findings**, or the source is switched off. Check **Configuration → Risk → Signal Sources**, then **Attach signal** on the risk to add it by hand. |
| A signal closed but is still listed on the risk. | Closed signals stay on the risk as the evidence trail and count under "closed" in the signal counts. |
| **Estimate withheld** on a scenario. | An input the estimate needs is not on record. The **Improve it** line names it (usually a liability cap or ACV on the contract, or a business unit's revenue). |
| The chain shows **Showing 40 of 180 nodes**. | Each column caps at 18 rows. Use **Depth**, **Data scope** or **Business unit** to narrow, or **Show all** on a column. |
| **Run agent now** did nothing visible. | The toast reports what it did: signals attached, proposed, re-scored, flagged stale. Zero across the board means no source cleared its threshold since the last run. |
| I renamed a scale level and the scores changed. | They did not; the risks followed their level **name** to its new number. Check the remap rows in each risk's history. |
| I cannot see **Risk** at all. | The module is not enabled for your organization. Ask your Coverbase representative. |
## Related
<CardGroup>
<Card title="Risk geography map" icon="map-location-dot" href="/user-guides/risk-geography-map">
The Geography tab: supplier sites, country counts and the vendor filters.
</Card>
<Card title="Admin and setup guide" icon="gear" href="/user-guides/admin-setup">
Vendor risk scales, service roll-up and the rest of the organization setup.
</Card>
<Card title="Contract components" icon="file-contract" href="/user-guides/contract-components">
The DPA, SLA and liability cap slots that feed component-gap signals and the cushion table.
</Card>
<Card title="Email and notifications" icon="envelope" href="/user-guides/email-notifications">
Where to turn the two risk notifications on or off.
</Card>
</CardGroup>
# How to run an assessment
Source: https://docs.coverbase.com/user-guides/running-an-assessment
A step-by-step walkthrough of the full assessment lifecycle, from getting the vendor into Coverbase to exporting the final report.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It follows one vendor through the whole assessment lifecycle, screen by screen. For the shorter version, see the [Assessment quick reference](/user-guides/assessment-quick-reference). For the wider analyst workflow (Radar, contracts, obligations), see the [Analyst and reviewer guide](/user-guides/analyst-reviewer).
</Info>
## What's in this guide
Each part stands on its own, so you can jump to the stage you need.
<CardGroup>
<Card title="Part 1: Get the vendor into Coverbase" icon="building" href="#part-1-get-the-vendor-into-coverbase">
Intake, or the manual New Vendor wizard.
</Card>
<Card title="Part 2: Create the assessment" icon="plus" href="#part-2-create-the-assessment">
One dialog: vendors, plan, name.
</Card>
<Card title="Part 3: Collect the evidence" icon="folder-open" href="#part-3-collect-the-evidence">
Five routes into the document set.
</Card>
<Card title="Part 4: Find your way around" icon="compass" href="#part-4-find-your-way-around-the-assessment">
The panel, the tabs, the Summary.
</Card>
<Card title="Part 5: Work the issues" icon="triangle-exclamation" href="#part-5-work-the-issues">
Bulk actions and individual results.
</Card>
<Card title="Part 6: Run follow-up cycles" icon="rotate" href="#part-6-run-follow-up-cycles">
Draft, send, reanalyze.
</Card>
<Card title="Part 7: Reviews and quality control" icon="user-check" href="#part-7-reviews-and-quality-control">
Per-domain reviewers and who can complete.
</Card>
<Card title="Part 8: Complete and export" icon="file-export" href="#part-8-complete-and-export">
Outcome, status, reassessment date, report.
</Card>
</CardGroup>
## Before you start
You will move faster with these to hand:
* The vendor name, website, and a security contact email address.
* Any evidence you already hold: SOC 2 report, policies, pen test results, certificates of insurance.
* The vendor's Trust Center URL if they publish one. Adding it to the vendor record lets Coverbase pull documents straight from the trust center later, saving a round trip.
* An Assessment Plan that matches the depth of review you need. Plans bundle the control sets, questionnaires, and collection method, so choosing the right one is most of the setup.
* Permission to create vendors and assessments. If a button described here is missing, check your role with an administrator.
## Two terms worth pinning down
<AccordionGroup>
<Accordion title="Inherent risk vs residual risk" icon="scale-balanced">
**Inherent risk** is the risk a vendor introduces based on what they do: the data they touch, the systems they connect to, the scope of the engagement. It is established before any evidence is reviewed.
**Residual risk** is what remains once their controls, certifications, and documentation have been evaluated. The assessment is what moves you from one to the other.
Both scores can sit on the vendor and on its individual services. [Where a vendor's score comes from](#where-a-vendors-score-comes-from) covers which an assessment writes to.
</Accordion>
<Accordion title="Assessment Plan" icon="clipboard-list">
An **Assessment Plan** is a reusable template defining what an assessment evaluates. Plans are managed centrally, so most users pick one rather than building an assessment up field by field.
</Accordion>
</AccordionGroup>
***
## Part 1: Get the vendor into Coverbase
An assessment attaches to a vendor record, so the vendor has to exist first. There are two ways to get one in.
* **The Intake module**: the standard path. A requester submits the vendor through a portal, answers a short set of questions, and Coverbase produces an inherent risk score as a by-product. You end up with a vendor record and a risk profile in one pass.
* **Manual creation**: the New Vendor wizard in the dashboard. Faster if you only need the record, but it does not establish inherent risk on its own.
<Note>
**If the vendor is already in Coverbase.** Check whether it already carries an inherent risk score. If it does, you need neither path. Skip straight to [Part 2](#part-2-create-the-assessment) and create the assessment. Re-running intake on a vendor that already has a current risk profile duplicates work.
</Note>
### Path 1 (recommended): through the Intake module
Intake determines how much risk a vendor introduces before anyone looks at their documentation. It answers two questions: what is the use case, and what is the scope?
**Why this is the better path.** The inherent risk result drives which control sets apply and how deep the assessment goes. A consulting vendor with no system access should not be assessed like a core processor, and intake is what tells Coverbase the difference.
Intake is completed by the requester (the business owner asking for the vendor) through a portal separate from the main dashboard. It runs in three steps: **Select Vendor**, **Additional Information**, **Review Questionnaires**.
<Warning>
You need your organization's intake link. Opening the intake path without it returns "Unable to identify intake portal. Please use the link provided by your organization." Find the link under **Intake → Request new vendor**.
</Warning>
<Steps>
<Step title="Name the vendor and describe the use case">
Enter the vendor name, or use **Help Me Choose** if you are still comparing options, then pick the use cases that apply. Coverbase generates these suggestions for the specific vendor, and you can add your own in the custom answer field.
Below, **Pre-Qualification** runs a quick analysis and checks whether you are about to duplicate a vendor you already have. If it finds a match it says so and offers **Not my vendor** if it has guessed wrong. It also surfaces existing vendors in good standing that might already cover the use case, along with their current use cases, services, and tags.
<Frame>
<img alt="Intake step 1 with use case selection and pre-qualification results" />
</Frame>
<Tip>
**Worth pausing here.** If Coverbase says the vendor is already onboarded, or that an approved vendor already covers the need, that is usually the end of the request. The same check tells you whether you can skip intake entirely.
</Tip>
</Step>
<Step title="Scope it to services, if relevant">
**Select Services or Product Lines** is optional. Choose the specific services you will be evaluating, or add one with **+ New Service**. Scoping here keeps the assessment focused on what you are buying.
The **Confirm** section follows, where you can check the details Coverbase gathered and attach any supporting documents you already hold: email threads, proposals, SOWs.
<Frame>
<img alt="Optional service scoping and the confirm section in intake" />
</Frame>
</Step>
<Step title="Answer the clarification questions">
Step 2 is headed **Additional Information**. Coverbase asks roughly four questions, generated for this vendor. They cover only what cannot be determined from public sources: whether personal data is involved, the size of the spend, whether you are in a regulated industry, and how deeply the vendor will integrate.
Each has a few preset answers plus a free-text option if none fits.
<Frame>
<img alt="Additional information step with generated clarification questions" />
</Frame>
</Step>
<Step title="Review the autofilled questionnaire">
Step 3 is headed **Review Questionnaires**. Rather than making the requester complete a long inherent risk questionnaire, Coverbase fills it in, often twenty or more responses, and tells you which ones need a human.
Three tabs across the top split the work: all responses, the ones still needing an answer, and the ones flagged for review. Work the flagged ones first.
Every response carries:
* **A confidence badge**: green *High confidence* where the evidence was clear, amber *Review this response* where it was not.
* **Reasoning**: why Coverbase chose that answer, with links to the sources it used. Expand it with **Read more**.
* **Answered / Reviewed checkboxes**: track your way through the list.
* **Select supporting documents**: optionally attach evidence to a response.
<Frame>
<img alt="Autofilled inherent risk questionnaire with confidence badges and reasoning" />
</Frame>
<Note>
**Human in the loop.** Autofilled answers are a starting point. Anything flagged for review is flagged because Coverbase is not confident, and the Reasoning usually says what was missing.
</Note>
</Step>
<Step title="Submit">
When every questionnaire reads **All done**, the panel switches to **Ready to Submit**. A summary of the vendor and any uploaded documents sits on the right so you can check it before you submit.
<Frame>
<img alt="Ready to submit panel with vendor summary" />
</Frame>
A risk analyst reviews the submission before it becomes an assessment, and can edit responses, ask the requester for clarification, or accept it and launch the assessment. At that point the vendor exists, carries an inherent risk score, and is ready for [Part 2](#part-2-create-the-assessment).
</Step>
</Steps>
### Path 2 (alternative): creating the vendor manually
Use this when you only need the record: a vendor being logged for administrative reasons, a supplier inherited from elsewhere, or a case where you already know the risk profile and will set it yourself.
<Warning>
**The trade-off.** Manual creation does not produce an inherent risk score. Until one is set, the assessment has nothing to calibrate its depth against, and the risk-domain view will have gaps. If you want that calibration, use Path 1 instead.
</Warning>
<Steps>
<Step title="Open the Vendors page and click New Vendor">
Go to **Vendors** in the left-hand navigation. The page has four tabs (Vendors, Services, Engagements, and Nth Parties), and you want the default **Vendors** tab. Click **+ New Vendor** at the top right. A three-step modal opens.
<Frame>
<img alt="Vendors page with the New Vendor button highlighted" />
</Frame>
</Step>
<Step title="Search for the vendor (step 1 of 3)">
The search field reads *Select from existing vendors or create new\...*. Start typing and Coverbase Entity Intelligence matches against its own database, labelling each result as a **Vendor** or a **Product**. Selecting a match pre-fills the details.
If there is no match, choose `Create vendor from scratch: "{your vendor}"`. Click it or press <kbd>Enter</kbd>.
<Frame>
<img alt="Vendor search with Entity Intelligence matches" />
</Frame>
</Step>
<Step title="Fill in the details (step 2 of 3)">
This step is headed **Modify Vendor Details**. If Entity Intelligence had data, most fields are already populated. Otherwise click **AI Autofill** to have Coverbase search the web, then correct anything it got wrong.
<Frame>
<img alt="Modify vendor details step with AI autofill" />
</Frame>
Only **Vendor Name** is required, but the rest save work later:
* **Website, Description, HQ Location, Use Cases**: context the AI draws on during assessment.
* **Security Contact Email**: used when Coverbase contacts the vendor.
* **Trust Center URL**: enables **Retrieve from Trust Center** in [Part 3](#part-3-collect-the-evidence).
* **Services**: you can then assess a single service rather than the whole vendor, which keeps scope tight.
* **Vendor Contacts**: these pre-fill every document request and follow-up you send.
* **Tags**: tags can drive which control sets apply, so if you tag by tier, do it now.
* **Risk Analysts, Relationship Owners, Watchers**: ownership and notification.
<Frame>
<img alt="Adding services, contacts, and tags to the vendor record" />
</Frame>
</Step>
<Step title="Custom fields and create (step 3 of 3)">
Step 3 is headed **Fill in additional fields** and shows whatever custom fields your organization has defined: contract amounts, audit dates, department, SLA, and so on. None are mandatory. Click **Create Vendor** and you land on the Vendor Overview page.
<Frame>
<img alt="Custom fields step of the new vendor wizard" />
</Frame>
<Note>
**Abandoning the wizard.** Closing part-way through prompts "Discard changes?" with **Keep editing** and **Close and discard**. Discarding leaves no partial vendor behind.
</Note>
</Step>
</Steps>
***
## Part 2: Create the assessment
<Tip>
**Simpler than it looks.** Assessment setup is a single dialog. Control sets and questionnaires are not chosen assessment by assessment. They come from the Assessment Plan you select.
</Tip>
<Steps>
<Step title="Open the Assessments page and click New Assessment">
Go to **Assessments** and click **+ New Assessment** at the top right. The list shows when each assessment was last updated, its outcome, score, status, auto-review progress, and both risk figures. It is sorted by **Last updated**, newest first.
If your organization has Zero Touch Assessments turned on, **Launch zero-touch assessment** sits beside **New Assessment**. It starts a lighter review that never contacts the vendor, and those runs are listed under **Zero Touch**, not here. See the [Zero Touch Assessment guide](/user-guides/zero-touch-assessments).
<Frame>
<img alt="Assessments list with last updated, outcome, score, status, and risk columns" />
</Frame>
</Step>
<Step title="Add the vendors and any services">
Click **+ Add vendor...** and pick the vendor, then optionally narrow to specific services. You can add more than one vendor, and each gets its own assessment from the same plan, which is the efficient way to start a batch of annual reviews. With more than one vendor the button reads **Create Assessments**. A batch of ten or more may be given lower priority and run during off-peak hours.
<Frame>
<img alt="New assessment dialog with vendors added" />
</Frame>
</Step>
<Step title="Choose the Assessment Plan">
This single choice determines what the assessment evaluates. The dropdown lists your saved plans. If an administrator has set a default plan, it is preselected and marked **Default**; otherwise the dropdown starts on **None**. Selecting a plan shows a summary beneath it: how many control sets and questionnaires it carries, whether documents are collected manually, automatically, or not at all, whether it targets residual or inherent risk, and who reviews it.
Read that summary before you continue; it is the fastest way to catch a plan that is heavier or lighter than the vendor warrants. **Configure** opens **Assessment Settings** on **Plans**, where plans are built and changed.
<Warning>
Leaving the plan on **None** creates an assessment with no control sets attached, which is rarely what you want. The assessment then shows "This assessment has no control sets or questionnaires configured" until you add one.
</Warning>
<Frame>
<img alt="Assessment plan dropdown with plan summary" />
</Frame>
<Note>
**Choosing a plan.** Plans built on your own control sets usually produce fewer and more relevant issues than a broad third-party questionnaire, which can run to several hundred expectations. Start with your own and add breadth only where you need it.
</Note>
</Step>
<Step title="Check the name, then create">
Expand **Customize assessment name**. Names are generated from a template rather than typed by hand (the default produces something like "2026 Acme assessment"), and a live preview shows the result as you edit. Leave it alone unless you have a reason to change it. Consistent names keep a long list of assessments searchable later.
Click **Create Assessment** (or **Create Assessments** for a batch). A single assessment opens straight away; a batch returns you to the list.
<Frame>
<img alt="Customize assessment name with template and live example" />
</Frame>
</Step>
</Steps>
***
## Part 3: Collect the evidence
Open the **Documents** tab. A **Collection mode** badge shows whether this assessment is collecting manually or automatically. In manual mode nothing is collected until you start it, and five routes are offered. They combine freely, and each card tells you how much is available before you click. In automatic mode the cards are replaced by the collection's progress through its stages, with **Pause** and **How collection works** beside it and **Switch to manual** in its actions menu.
<Frame>
<img alt="Documents tab with the five evidence collection routes" />
</Frame>
* **Import from existing vendor docs**: anything already on the vendor profile. Fastest route for a reassessment.
* **Request from vendor**: manages the assessment portal, and shows the portal's current status so you can see where the vendor has got to.
* **Request automatic collection**: switches this assessment to automatic collection.
* **Import from Coverbase Library**: documents Coverbase collected for this vendor itself, by requesting them from the vendor and retrieving what the vendor publishes on its trust center. Check the count; for well-known vendors it is often substantial. Nothing your organization uploads is ever part of this library. See [Document library](/products/document-library).
* **Retrieve from Trust Center**: pulls from the vendor's public trust center. Only available with a Trust Center URL on the vendor record.
Below the cards, **Upload vendor documents** takes files you hold yourself.
In manual mode, documents alone do not start the analysis. Once at least one is attached, the left panel reads "ready to analyze" and offers **Start Assessment**. A vendor submitting the portal starts it for you, and automatic collection starts it once the documents are ready.
A sixth route needs no collection at all: where a control set allows it, the AI researches the public web while evaluating a control. That evidence is filtered on publisher accountability before it can be cited, and every accepted page carries its grade and its age. See [Evidence quality and source credibility](/user-guides/evidence-quality).
<Steps>
<Step title="If you are using the portal, send the request">
The vendor gets a branded portal with a due date, your message, and a checklist of what you need: questionnaires and document requests, with required items marked. They cannot submit until the required parts are done, and progress is visible to both sides.
When they submit, their responses are finalized, their documents are attached to the assessment, and the analysis starts. No handoff needed.
If the vendor has uploaded documents but not submitted, the **Documents** tab says so and offers **Submit Portal**, which finalizes the portal on their behalf. Reopening the portal is the only way back.
<Frame>
<img alt="Vendor-facing assessment portal with upload area and required sections" />
</Frame>
</Step>
<Step title="Wait for analysis">
Analysis typically takes 20 to 30 minutes depending on document volume. A long SOC 2 report takes longer than a certificate of insurance. You do not need to keep the tab open.
The left panel tracks the assessment through your organization's lifecycle stages. By default these are **Collecting Documents**, **Analyzing Controls**, and **Review Results**; any stages your administrator has added appear in order alongside them. A plan whose control sets need no documents skips **Collecting Documents**. The panel also tells you what it is waiting for, which at the start is at least one document, with a shortcut such as **Go to documents** or **Start Assessment**.
<Frame>
<img alt="Assessment stage tracker showing the lifecycle stages" />
</Frame>
</Step>
</Steps>
***
## Part 4: Find your way around the assessment
There is a lot on this page. Three areas matter.
### The left panel
Current stage, what it is waiting for, and a shortcut into the work. Once results are ready it also offers an **Export** menu. Below that, **Details** holds the assignee, inherent risk, risk target, and services, followed by cards for the **Plan** the assessment came from, its **Control Sets**, its **Questionnaires**, and custom **Properties**.
The **Actions** menu at the top right of the page holds **Rerun**, **Clone**, **Cancel run**, **Export**, and **Archive**.
### The tabs
Once results are in, eleven tabs run across the top. Most of the time you need the first two, **Summary** and **Issues**. The rest carry supporting detail and the audit trail: Controls, Findings, Emails, Work Queue, Documents, Activity, Notes, Properties, and SLAs.
### The Summary tab
Once an outcome or a recommendation has been recorded, **Recommendation** sits at the top: the human conclusion. It appears in exports, so write it properly rather than leaving it thin.
Then a band showing the **Score** as a percentage with a compliance band, how many domain reviews are complete, and **Complete Assessment**.
Then the risk domain table: **Overall Vendor Risk** plus a row per domain, each with inherent risk, residual risk, and the assigned reviewer. Domains vary by plan; a broad plan can produce nine or more, covering things like AI & Emerging Technology, Operational Resilience, Concentration & Fourth-Party Risk, and Reputational & ESG alongside the familiar Data Security and Privacy.
Rows reading "Not set" against residual risk have not been reviewed yet. Those are your gaps.
<Frame>
<img alt="Assessment summary tab with recommendation, score band, and risk domain table" />
</Frame>
***
## Part 5: Work the issues
The **Issues** tab holds one result for every control in the assessment. It opens filtered to the results raised as issues.
### Reading the top of the page
* **Risk domain selector**: narrow to a single domain.
* **Control Score**: the score out of 100%.
* **Open Issues**: open count against the total.
* **Vendor Score** (**Service Score** on a service-scoped assessment): inherent and residual risk.
If any follow-ups exist, a bar summarizes them (how many await a response, how many are still drafts) alongside **Send follow-ups**. Once a round is out, that button becomes **Manage sent follow-ups**, and an actions menu beside it holds **Configure portal**, **Import responses**, and **Download workbook**. The workbook and import options are there for vendors who would rather work in a spreadsheet than the portal.
<Steps>
<Step title="Orient yourself in the list">
Three toggles switch the view (all results, issues only, and open follow-ups), each with a count. **Group by** defaults to **Control Section**, so results arrive clustered by control set and section, with the reviewers for that section shown on the group header.
Each row shows the control reference, the expectation in short form, status chips such as *Missing document* or *Awaiting*, any linked findings, the weight, and the result.
<Frame>
<img alt="Issues tab with view toggles, grouping, and result rows" />
</Frame>
</Step>
<Step title="Handle the straightforward ones in bulk">
Select rows, or **Select all**, and an action bar appears with everything you can do at once. **Resolve** closes open issues as **Mark as mitigated** or **Accept risk**. **Add Finding**, **Create follow-ups** (the count comes along, so you can draft dozens in one sweep), **Delete follow-ups**, **Preserve**, and **Draft new email** sit beside it, and the menu at the end holds **Mark as not an issue**. A selection of resolved issues offers **Reopen issue** instead.
Bulk-drafting follow-ups for every missing-document issue takes one action rather than a hundred.
<Frame>
<img alt="Bulk action bar on the issues list" />
</Frame>
</Step>
<Step title="Open an individual result">
Click a row to open it. A status banner sits at the top with the actions available for that state. An open issue reads **Issue found** and offers **Draft follow-up**, **Add Finding**, **Not an issue**, and a **Resolve** menu (**Mark as mitigated** when the vendor has fixed it, **Accept risk** to keep it on record without further action). A result that is not an issue offers **Mark as issue** instead. Once a follow-up is out, the banner shows its status, **Awaiting response** and then **Response received**, and a resolved issue offers **Reopen issue**.
The left column shows the control: the **Expectation** (what must be true), the **Question** as it is put to the vendor, the **Guidance** for judging evidence, which **Control Set** it came from, and its **Weight**.
Beneath it, **Evaluation** gives the score and compliance band, and a bulleted analysis explaining the verdict. Each claim carries an **Evidence** reference you can click through to. Four controls sit above it: **Correct the AI** to adjust the guidance and rerun the analysis, **Rerun** to evaluate this control again as it stands, **Preserve** to pin a result so later runs do not overwrite it, and **Edit**.
<Frame>
<img alt="Individual control result with expectation, guidance, and cited evaluation" />
</Frame>
</Step>
<Step title="Follow the citation to the source">
The right column holds **Evidence**, **Follow-up**, **Findings**, and **Activity**, with prev/next controls so you can work straight through the list. Each piece of evidence names its source document and page, quotes the passage, and shows a preview of the page with the passage highlighted.
<Frame>
<img alt="Evidence panel with the cited passage highlighted in the source document" />
</Frame>
<Tip>
**Why the citation matters.** When an examiner asks why a control passed, the answer is the quoted passage from a named document on a specific page.
</Tip>
</Step>
</Steps>
***
## Part 6: Run follow-up cycles
Follow-ups are drafted individually and sent together, so the vendor gets one consolidated request rather than a trickle of emails.
<Steps>
<Step title="Draft the follow-up">
From a result, draft a follow-up question. **AI Autofill** writes a first pass that references what the evidence already showed and asks only for the gap, which is usually better than starting from scratch. **Use control question and response** reuses the original control wording instead.
Under **Required document types** you can name what the vendor should attach, so the request is specific rather than "please send evidence".
Saving creates a draft. Nothing reaches the vendor until the drafts are included in a follow-up questionnaire sent through the portal.
<Frame>
<img alt="Draft follow-up dialog with AI autofill and required document types" />
</Frame>
</Step>
<Step title="Send them">
Back on the **Issues** tab, the bar shows how many drafts are waiting. **Send follow-ups** opens a dialog where you choose which drafts go out, set an optional portal due date and instructions, and decide whether to email the vendor. Sending reopens the assessment portal (or creates one) with a questionnaire built from your questions. **Configure portal** controls what the vendor sees; **Manage sent follow-ups** tracks what is already out and resends the notification.
<Frame>
<img alt="Follow-up bar showing drafts waiting to send" />
</Frame>
</Step>
<Step title="Let the reanalysis run">
When the vendor submits, only the controls selected for follow-up, and any controls that depend on their answers, are analyzed again against the new evidence. Everything else is left alone.
A result that has come back reads **Response received**, and the analysis is rewritten to account for what the vendor said, often moving from *Not Compliant* to *Fully Compliant* where the gap was documentation rather than practice.
If the vendor's follow-up answer differs from the response the analysis used, the control shows both and asks you to **Resolve response conflict**: accept the follow-up as the corrected response, keep the previous one, or choose a different response. The control is rerun with your choice, and anything other than accepting the follow-up needs a reason. To keep the current response on many controls at once, select them on the **Issues** tab and use **Keep current response**.
<Frame>
<img alt="Result showing response received and the rewritten analysis" />
</Frame>
<Note>
**Follow-up versus rerun.** A follow-up reanalyzes only the affected controls. If you have changed the plan or control sets, or want everything re-evaluated from scratch, use **Rerun** from the assessment **Actions** menu instead.
</Note>
</Step>
</Steps>
***
## Part 7: Reviews and quality control
Each risk domain can carry its own reviewer, which is what lets several teams work one assessment: InfoSec on the security domains, Legal on the contractual ones, Compliance on regulatory. The **Summary** tab reports progress as a count of completed reviews.
A reviewer opens their domain with **Start review**. Domains show *Not started* until someone does, and their residual risk stays "Not set".
<Frame>
<img alt="Risk domain rows with reviewers and Start review actions" />
</Frame>
<Warning>
**Who can complete, and when.** **Complete Assessment** becomes available once the assessment reaches **Review Results**, and is grayed out while an analysis run is still in progress. It does not wait for the domain reviews. When your organization restricts completion, only the vendor's risk analysts and administrators can complete an assessment, and the button warns them when they are about to override reviews that are still open.
</Warning>
* Reviewers are set per domain or control set and can be changed until that domain's review is complete.
* Reviewers are notified when results are ready for them.
* Risk analysts and administrators can resend reminders.
* **Restrict assessment completion to risk analysts and admins**, in **Assessment Settings > Workflow**, stops anyone else from completing assessments.
If your organization has added its own stages after **Review Results**, such as a quality control pass, move the assessment into them with **Set status** in the stage card's menu. **Complete Assessment** stays available in those stages.
***
## Part 8: Complete and export
<Steps>
<Step title="Complete the assessment">
When the issues have been worked and the reviews returned, click **Complete Assessment** on the **Summary** tab.
<Frame>
<img alt="Complete Assessment button next to the score and review progress" />
</Frame>
The dialog asks for four things:
* **Action**: approve, reject, or whichever outcomes your organization uses.
* **Vendor Status**: where this leaves the vendor in its lifecycle, for example *Active*. A service-scoped assessment asks for **Service Status** instead.
* **Next Vendor Reassessment Date**: set for you based on risk tier and the date you completed, typically a year out. Change it if this vendor needs watching sooner.
* **Recommendation**: the written conclusion that appears in exports.
**Risk Scoring Changes** expands to show how this assessment moved the vendor's scores, which is worth a look before you confirm. If issues are still open, a checkbox at the bottom accepts the risk on all of them as you complete.
<Frame>
<img alt="Complete assessment dialog with action, vendor status, reassessment date, and recommendation" />
</Frame>
</Step>
<Step title="Export the results">
Once complete, the panel reads **Complete** and offers **Export Report** as PDF, Excel, or CSV, plus Word if your organization uses a custom Word report template.
Match the format to the audience. PDF for anything leaving the company. Excel or CSV when someone wants to sort and filter the results themselves. Word when the output needs to drop into an existing house template. The Word export is driven by your organization's branded template, and [Custom Word report templates](/reporting/assessment-report-templates) covers changing what it pulls in.
<Frame>
<img alt="Export report menu with PDF, Excel, CSV, and Word formats" />
</Frame>
<Note>
**A word on report length.** The fullest export includes every result, all document evidence, the activity log, follow-ups, and notes, and can run to hundreds of pages. Use it when someone has asked for the complete file. For examiners and executives, the summary-level report is usually the better choice.
</Note>
</Step>
</Steps>
### Where a vendor's score comes from
An assessment writes its residual risk to whatever it was scoped to. A vendor-scoped assessment moves the vendor's score. A service-scoped assessment scores those services and, by default, leaves the vendor's score unchanged.
This is why a service assessment can come back high while the vendor profile still reads medium.
**Risk Roll-up** carries the service score up to the vendor. Once an administrator turns it on for a risk type (see [Step 5 of the admin setup guide](/user-guides/admin-setup#decide-whether-service-scores-set-the-vendors-score)), a vendor takes the highest score among its services instead of carrying its own. Services with an inactive, discontinued, or denied status are excluded.
Risk domain rows roll up as well as the overall score. A vendor's Data Security row follows the highest Data Security score among its services.
<Note>
Roll-up is off until an administrator turns it on, and it applies only to scores set after that. Older vendors can be brought in line with **Recalculate now**.
</Note>
#### Overriding it for one vendor
Open the score on the vendor's **Risk Profile** and use **Automatically infer from services**.
With it on, the services set the score. The **Risk Score** field is read-only and **Clear risk score** is hidden, because the next change to the services would overwrite anything you entered.
<Frame>
<img alt="Edit Residual Risk Score popover with Automatically infer from services switched on and the score field read-only" />
</Frame>
With it off, you set the score by hand and record the reason in the note field. The vendor then ignores the organization setting, including one turned on later.
**Use organization default** appears once a vendor has its own score, and returns it to the organization setting.
<Frame>
<img alt="Edit Residual Risk Score popover with the switch off, showing Use organization default and an editable score field" />
</Frame>
<Tip>
If the switch is missing, the vendor has no services to roll up from. Add a service first.
</Tip>
***
## Related guides
<CardGroup>
<Card title="Assessment quick reference" icon="bolt" href="/user-guides/assessment-quick-reference">
The one-page version: steps, tips, common scenarios, and a troubleshooting table.
</Card>
<Card title="Analyst and reviewer guide" icon="user-check" href="/user-guides/analyst-reviewer">
The wider daily loop, including Radar alerts, contracts, and obligations.
</Card>
<Card title="Admin and setup guide" icon="sliders" href="/user-guides/admin-setup">
How assessment plans, control sets, scales, and reviewers are configured.
</Card>
<Card title="Evidence quality and source credibility" icon="shield-check" href="/user-guides/evidence-quality">
How web evidence is graded and filtered before it can be cited, and where you set the bar.
</Card>
<Card title="Control Set library" icon="shield-check" href="/control-library">
What ships in the box, and how control sets differ from questionnaires.
</Card>
</CardGroup>
<Card title="Need help?" icon="envelope" href="mailto:support@coverbase.ai">
Email [support@coverbase.ai](mailto:support@coverbase.ai), or ask your Coverbase contact to run a live working session with your team.
</Card>
# How to run an RFP
Source: https://docs.coverbase.com/user-guides/running-an-rfp
A step-by-step walkthrough of the RFP lifecycle: draft one with the AI wizard, compare the field without contacting anyone, score against your rubric, and record the decision.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It follows one sourcing event from a sentence of intent to an awarded vendor with a decision memo. For what RFP Platform is and where it fits, see [RFP Platform](/products/rfp-platform). For what happens after the award, see [How to run an assessment](/user-guides/running-an-assessment).
</Info>
## What's in this guide
Each part stands on its own, so you can jump to the stage you need.
<CardGroup>
<Card title="Part 1: Draft the RFP" icon="wand-magic-sparkles" href="#part-1-draft-the-rfp">
Eight wizard steps, from one sentence to a complete RFP.
</Card>
<Card title="Part 2: Find your way around" icon="compass" href="#part-2-find-your-way-around">
Seven sections, in the order you work through them.
</Card>
<Card title="Part 3: Run it without outreach" icon="user-secret" href="#part-3-run-it-without-outreach">
Compare the field before contacting anyone.
</Card>
<Card title="Part 4: Score the responses" icon="scale-balanced" href="#part-4-score-the-responses">
Rubric scoring, evidence, and must-have failures.
</Card>
<Card title="Part 5: Compare and decide" icon="table-columns" href="#part-5-compare-and-decide">
Cross-vendor comparison, pricing, and the decision memo.
</Card>
<Card title="Part 6: Onboard the winner" icon="arrow-right-arrow-left" href="#part-6-onboard-the-winner">
Hand the vendor to intake without re-keying anything.
</Card>
</CardGroup>
## Before you start
You will move faster with these to hand:
* **A sentence about what you need.** Not a specification. "We need to replace our applicant tracking system for about 12 recruiters, integrated with our HRIS and Microsoft 365" is enough for the wizard to work from.
* **Your hard constraints.** The things a vendor cannot talk you out of: an access scope you will not grant, a certification you require, a jurisdiction your data cannot leave. These become must-have requirements.
* **A rough timeline.** When responses are due and when you need to decide. The wizard proposes dates from those two, and you can move any of them.
* **Permission to create RFPs and vendors.** If a button described here is missing, check your role with an administrator.
## Two terms worth pinning down
<AccordionGroup>
<Accordion title="Rubric vs questionnaire" icon="list-check">
The **rubric** is what you are evaluating: categories, the criteria under each, their weights, and the ideal answer for each criterion. It is how you decide.
The **questionnaire** is what you ask vendors. Each question is tied back to a rubric criterion, so an answer arrives already attached to the thing it is evidence for. The wizard builds both, and links them.
</Accordion>
<Accordion title="Silent RFP" icon="user-secret">
A **silent RFP** researches how each shortlisted vendor would most plausibly answer your questionnaire, from public information about their product. Nobody is contacted. It exists so you can narrow a field of ten to a field of three before you ask anyone to spend a week writing a response.
Its output is Coverbase's research, never a vendor's own words, and every screen that shows it says so.
</Accordion>
</AccordionGroup>
***
## Part 1: Draft the RFP
From **RFPs**, click **New RFP**. The list above the table shows how many RFPs are active, which vendors have not yet responded, and which responses or decisions fall due within seven days.
<Frame>
<img alt="The RFPs list with summary cards above a table of RFPs" />
</Frame>
You are asked how you want to build it.
<Frame>
<img alt="Choosing between the AI wizard and manual creation" />
</Frame>
**Create manually** opens a short form: a name, a category, and a description. Vendors, requirements and questions you add later from the RFP page. Use it when you are recreating an RFP you already have.
**Build it with AI** (click **Start with AI**) is the eight-step wizard below. Nothing it produces is final; every step is editable, and nothing is written to your organization until the last one.
### Step 1: What you need
Describe what you are buying in a few sentences, in your own words. Include the constraints, because they carry through to the requirements.
<Frame>
<img alt="The brief step of the RFP wizard" />
</Frame>
### Step 2: Clarify
The wizard reads your brief and asks the handful of questions that would change the RFP: how many users, which systems it must integrate with, what data it will touch, what your budget shape is.
<Frame>
<img alt="Generated intake questions" />
</Frame>
Answer what you know, then click **Draft my RFP**. Anything optional you skip is treated as unstated rather than guessed at. A few questions are marked **Required**, because the rest of the draft leans on them. If one is blank, **Draft my RFP** flags it and scrolls you to it. **Skip and draft now** drafts from your brief without the answers.
### Step 3: Description
The wizard drafts the RFP's name, its short description, the longer narrative that vendors read, and a scope of what is in and out.
<Frame>
<img alt="The drafted description and proposal narrative" />
</Frame>
<Tip>
The **Not quite right?** box is the faster path when something is off in tone or emphasis. Typing "Make the security section firmer, and say we will not grant tenant-wide mailbox access" and clicking **Re-draft** produces a better redraft than editing the paragraph by hand. Re-drafting replaces edits you made to the fields above it.
</Tip>
### Step 4: Timeline
Dates are proposed from your decision deadline and the size of the questionnaire, with the reasoning shown. Move any of them.
<Frame>
<img alt="The proposed timeline and lifecycle stages" />
</Frame>
Three settings live here:
| Setting | What it does |
| - | - |
| **Q\&A phase** | Opens a window where vendors ask questions and every answer is published to all of them. |
| **Collect pricing** | Asks vendors for a pricing schedule inside the response, rather than handling commercials separately. |
| **Blind scoring** | Hides vendor names from reviewers while they score, so the rubric drives the result. |
### Step 5: Vendors
Choose how many vendors to research (between five and ten) and click **Research vendors**. The wizard summarizes how the market looks and proposes a shortlist, each vendor with what it is known for, why it fits your brief, what to watch out for, and a contact address where one is public. **Find more** runs the research again and adds new names.
<Frame>
<img alt="Researched vendor suggestions" />
</Frame>
Click **Add** on the ones you want to invite, or take the whole set with **Add all** and pare it back from there. Check each contact email before you continue. A vendor the research missed goes in under **Add a vendor yourself**. You are not committing to a shortlist size here. More can be added from the RFP's Vendors section at any time.
<Warning>
Vendor research is a starting point, not a market survey. It reflects what is publicly documented, which favors vendors who publish. Add the ones you already know about.
</Warning>
### Step 6: Requirements
Click **Suggest requirements** and the wizard proposes the rubric: weighted categories, the criteria under each, and the ideal answer for every criterion.
<Frame>
<img alt="The proposed rubric with weighted categories" />
</Frame>
Take time on this step. The rubric is what every later screen scores against, so a criterion that does not matter to you will pull the ranking around.
<Tip>
Mark the criteria you will not compromise on as **Must have**. A response that does not clearly clear a must-have is flagged as failing it, and ambiguity counts as a failure rather than a pass.
</Tip>
### Step 7: Questions
The wizard writes the vendor-facing questionnaire, spread across the rubric in proportion to each category's weight so every criterion has evidence behind it. Choose how many questions you want and click **Generate questions**.
<Frame>
<img alt="The generated vendor questionnaire" />
</Frame>
### Step 8: Review
Everything the wizard is about to create, on one screen.
<Frame>
<img alt="The wizard review step" />
</Frame>
Clicking **Create RFP** creates the RFP, its rubric, its questionnaire, the vendor records, and the invitations, all as one transaction. It lands as a **draft**. No vendor is contacted until you publish it with **Publish RFP**, then send invitations from the Vendors section.
***
## Part 2: Find your way around
<Frame>
<img alt="The RFP overview section" />
</Frame>
| Section | What lives there |
| - | - |
| **Overview** | Details, lifecycle and timeline, description, proposal narrative, internal notes, the original brief and your intake answers, rubric versions |
| **Vendors** | Invitations, how each vendor was sourced, portal links, onboarding |
| **Submissions** | Responses, real and researched, with scores and ranks, and the silent-RFP control |
| **RFP Requirements** | The rubric: categories, criteria, weights, ideal answers, and the linked questionnaires |
| **Comparison** | Score matrix, leaderboard, cross-vendor comparison, pricing, decision memo |
| **Q\&A** | Vendor questions and the answers published back to every bidder |
| **Activity** | Every event on the RFP, including which AI steps ran and who ran them, alongside internal notes |
Everything on the Details card is editable at any stage, draft or not. Category and scoring scale offer their alternatives directly; the owner is a person picker; feature toggles flip in place. **Passing score** sets the minimum a response needs to pass.
On a draft, **Publish RFP** sits beside **Edit**. The **Actions** menu pauses an active RFP, and cancels or archives one that has not been awarded. To move an RFP to another lifecycle stage by hand, click **Move here** on that stage in the lifecycle panel.
<Frame>
<img alt="The RFP vendors section" />
</Frame>
**Invite Vendor** takes a vendor, and optionally a contact email and a response due date. **Send Invitation** then opens the invitation email for you to review and send. A vendor gets a portal link only when the RFP has a response questionnaire and the invitation has a contact email, because the portal admits only that email's domain. Each vendor's **Actions** menu withdraws the invitation or disqualifies the vendor, and **Put back in the running** reverses either.
***
## Part 3: Run it without outreach
A silent RFP researches how each invited vendor would most plausibly answer your questionnaire, so you can compare the field before asking anyone for real work. Click **Run silent RFP** in the Submissions section. It runs in the background (research, then scoring against your rubric, then the comparison), so you can leave the page and come back. At least one vendor must be invited first.
<Frame>
<img alt="The submissions section with the silent RFP control" />
</Frame>
Three things to know:
<AccordionGroup>
<Accordion title="These are not vendor responses" icon="triangle-exclamation">
They are Coverbase's research, modeled from public information about each product. Nobody was contacted, and no vendor has seen or agreed to any of it. Do not present a researched response to a vendor, an auditor, or a committee as something the vendor said.
</Accordion>
<Accordion title="A real response always wins" icon="shield-check">
Vendors who have already submitted are skipped. **Replace real submissions** exists and is off by default; even when on, it only ever adds a researched estimate alongside the real answer. Re-running a silent RFP never deletes a vendor's own words.
</Accordion>
<Accordion title="Confidence is about the vendor, not the prose" icon="gauge">
Each answer carries the model's confidence that it reflects the vendor's real position, plus the basis it used. A fluent answer with low confidence is a plausible guess.
</Accordion>
</AccordionGroup>
***
## Part 4: Score the responses
To score one submission with AI, pick it beside **Auto-score with AI** under **Rubric Scores** in the Comparison section, or open the submission and click **Re-evaluate with team input**. Each criterion in the rubric gets a suggested score, the reasoning behind it, and the verbatim span of the response the score rests on. A silent RFP scores its researched responses for you.
The suggestion sits next to the reviewer's own score and never replaces it. Re-running the scorer leaves anything a person entered exactly as it was.
Three rules apply to the suggestion:
* **A score must cite the response.** A criterion the response never addresses scores 0 with no quote, rather than an inferred number.
* **A must-have fails on ambiguity.** Must-have criteria pass only when the response clearly clears the bar. Failures are listed above the scoring table.
* **A renamed criterion is surfaced, not dropped.** Scores returned for criteria that are no longer on the rubric are reported rather than silently discarded.
Scoring also reads the commercial terms out of the response, which is where the pricing table in the next part comes from.
### Scoring a demo, together
Each requirement is its own card, and everyone evaluating the submission writes on it. Your assessment sits at the top; below it are your colleagues' notes, each under their name.
This is built for the demo itself:
* **The score is optional.** Pick **No score** and write only what you saw. An observation without a number reaches the team and the re-evaluation.
* **The score and the note save separately.** Type a note twenty minutes after entering a score and the score stays where it was.
* **Turn on "Saw this first-hand"** for anything you watched in the demo or heard on a reference call rather than read in the response.
When the session is over, click **Re-evaluate with team input**. Coverbase re-reads the response together with every note the team recorded. A note marked as seen first-hand is treated as evidence the written response does not contain: it can move a score, the rationale says whose observation moved it, and where the observation contradicts the response, the observation wins.
Re-evaluating never touches anyone's own score or notes. It rewrites the suggestions only.
<Tip>
Different stakeholder groups see different things in the same demo. Security watches the integration scopes, the hiring team watches the workflow. Both writing on the same rubric row turns a demo into recorded evidence.
</Tip>
<Frame>
<img alt="The RFP requirements section" />
</Frame>
***
## Part 5: Compare and decide
### Cross-vendor comparison
The comparison reads every submission together. What separates two bidders only shows in the contrast between them.
<Frame>
<img alt="The comparison section" />
</Frame>
When any submission in the set is researched rather than real, the summary says so and weighs it lower. Ranks are written back onto the submissions, and the leaderboard shows each vendor's position against where it sat before, so a re-run makes its own effect visible.
You are not bound by the ranking it produces. Drag any row by its handle to put the field in the order you believe is right, and the board renumbers from the top. A manual reorder is recorded in Activity, so the override is visible next to the comparison it replaced.
To award, click **Mark winner** on the winning row. The RFP moves to **Awarded**, and from then on the leaderboard is a record: rows can no longer be dragged or marked. The same holds for a cancelled or archived RFP.
### Pricing and total cost
Year-one cost and three-year total cost sit side by side, each with a badge for how firm the number is:
| Badge | Meaning |
| - | - |
| **Published price** | A public list price you can hold them to. |
| **Quoted to us** | A specific figure for this buyer. |
| **Indicative** | A range, or a "starting at". |
| **Withheld** | The response did not say. |
A response that never stated a figure shows blank rather than zero, because "contact us" is not free. Watch-outs such as uncapped uplift, implementation billed separately and seat minimums are read out of the response and shown next to the numbers.
### Q\&A
Vendor questions and the answers you publish back to all of them. **Draft with AI** writes an answer from what the RFP establishes, for you to edit before publishing. **Publish to FAQ** shares the answer with every bidder; **Save (Private)** keeps it internal. The section works only when the RFP's **Q\&A phase** is enabled.
<Frame>
<img alt="The Q&A section" />
</Frame>
If the RFP does not answer the question, the draft says so and suggests what the RFP should add.
### Decision memo
After you award, **Write the memo** produces the record of why: the recommendation, the reasoning, each runner-up with the specific reason it lost, the risks you are knowingly accepting, and the conditions the winner must meet before signature.
Where a researched response stood in for a real one, the memo says so. Somebody reading it in a year needs to know which part of the decision rested on research.
<Frame>
<img alt="The RFP activity feed" />
</Frame>
***
## Part 6: Onboard the winner
From the Vendors section, **Onboard** opens the vendor form prefilled with everything the RFP already established: the research that shortlisted them, the invitation contact, the RFP's description as the use case, and anything flagged during sourcing. **Onboard vendor** saves the record and takes you to the vendor's page.
<Frame>
<img alt="Onboarding a vendor from an RFP" />
</Frame>
From there the vendor enters the normal program: [Autonomous Intake](/products/autonomous-intake) for due diligence, then [Assessment Copilot](/products/assessment-copilot), reusing the responses and evidence the RFP already collected.
***
## Running an RFP from chat
Everything above is available through the [MCP server](/mcp/overview), so an RFP can be drafted and compared in a conversation. Reads go through `query_rfps`; writes go through `mutate(entity="rfp", ...)` and ask you to confirm before anything is created.
A typical exchange:
1. "Draft an RFP to replace our applicant tracking system for 12 recruiters, integrated with our HRIS and Microsoft 365. No tenant-wide mailbox access."
2. "Research vendors for it, and suggest requirements."
3. "Create it." You confirm, and the RFP, rubric, questionnaire and invitations are created together.
4. "Run it silently and compare them." Researched responses, then the cross-vendor comparison.
The same rules apply: researched responses are labeled as research everywhere they appear, and every write asks for confirmation first.
***
## Common questions
<AccordionGroup>
<Accordion title="Can I edit an RFP after publishing it?" icon="pen">
Yes. Every field on the Details card, the timeline, and the rubric stay editable after publication. Rubric changes are versioned, so you can see what the rubric looked like when a given submission was scored.
</Accordion>
<Accordion title="What happens if I re-run vendor research?" icon="rotate">
New suggestions are added to the ones you already have. Vendors you have already invited are matched by name rather than duplicated, and re-inviting a vendor who declined puts them back in the running.
</Accordion>
<Accordion title="Do I have to use the AI at all?" icon="hand">
No. **Create manually** skips the wizard, and every AI action on the RFP page is something you click rather than something that happens. The rubric, the questionnaire and the scores can all be entered by hand.
</Accordion>
<Accordion title="Who can see a researched response?" icon="eye">
Anyone with access to the RFP, and it is labeled as research everywhere it appears. Researched responses are never sent to vendors and never appear in a vendor's portal.
</Accordion>
<Accordion title="How do I let someone score a demo without giving them the whole RFP?" icon="user-check">
Scoring is its own permission. A role with **RFP: read** plus **RFP evaluation: create and update** can score submissions and write demo notes, but cannot edit the RFP, change its vendors, or award it. Siloed Members have exactly that by default; for Auxiliary Members or Guests, an admin grants **RFP evaluation** through a custom role.
</Accordion>
<Accordion title="Can two people score the same requirement?" icon="users">
Yes, that is the intent. Each person's score and notes are stored separately against the requirement and shown under their name. Nobody overwrites anybody.
</Accordion>
</AccordionGroup>
## Related
<CardGroup>
<Card title="RFP Platform" icon="clipboard-list" href="/products/rfp-platform">
What RFP Platform is and where it fits.
</Card>
<Card title="How to run an assessment" icon="list-check" href="/user-guides/running-an-assessment">
What happens after the award.
</Card>
<Card title="Requesting a vendor" icon="cart-shopping" href="/user-guides/requesting-a-vendor">
The intake path the winner is handed to.
</Card>
</CardGroup>
# Sanctions screening guide
Source: https://docs.coverbase.com/user-guides/sanctions-screening
How continuous sanctions and watchlist screening works, how to read an identity confidence score, and how to clear a match without guessing.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. Screening is a tab in every vendor's [Vendor Intelligence](/products/vendor-intelligence) section, plus a queue of its own. For every source, list and category screening checks, see [Screening coverage and sources](/user-guides/screening-coverage).
</Info>
Corporate registrations tell you the company is real. People intelligence tells you who runs it. This page tells you whether the company or those people appear on a sanctions, watchlist, criminal or legal source. Not once at onboarding, but on a schedule, for as long as you keep the vendor.
Two things make it different from the rest of Vendor Intelligence.
**Every screen is recorded, including the clear ones.** "We screened this vendor on this date, against these sources, and found nothing" is the record an examiner asks for. A missing record proves nothing, so the vendor page shows the run history whether or not there is anything to review.
**The score is about identity, not severity.** It is easy to misread, so it has its own section below.
## Where it lives
Screening appears in two places, and they are for two different jobs.
**On a vendor**: open a vendor, go to **Vendor Intelligence**, and pick the **Screening** tab. This is the view when you already care about one supplier.
<Frame>
<img alt="The Screening tab for a vendor, showing an open sanctions match, its identity confidence, and the history of scheduled screens." />
</Frame>
**In the review queue**: **Screening** in the left navigation. Every open match across every vendor, oldest first. This is the view when your job is to clear the queue rather than to look at one vendor. **Needs review**, **Confirmed** and **Resolved** switch between open and decided matches, and the source buttons beside them filter the list.
<Frame>
<img alt="The screening review queue showing open matches across several vendors, with counts for matches needing review and the age of the oldest one, the Needs review, Confirmed and Resolved buttons, source filters, and the Configuration and Ad hoc screen buttons." />
</Frame>
The queue is separate from Findings. A screening match is triaged on a different question from the rest of your work (*is this listed record this vendor?*), and mixing it into a general work queue buries the one kind of alert that carries a regulatory deadline. Each new match also opens a finding by default, so it has an owner and a due date while it waits. See [Deciding](#deciding).
## Identity confidence is not severity
Every match carries a score. It answers one question: **how confident are we that this listed record is this vendor?**
It does not tell you how serious the listing is. A match at 0.95 against an adverse-media article means we are confident the article is about this subject, not that the article is damning. A confirmed sanctions listing at 0.72 is far more urgent than a high-confidence mention in a news story.
<Warning>
Read the source, not the score. The score decides whether it is them. The listing decides what it means.
</Warning>
Screening runs on thin identity data: a name, usually a country, sometimes a registration number, almost never a date of birth. That is not much to match on, so **false positives are expected and are not a defect**. A common surname or a generic trading name will produce candidates that are not your vendor. Clearing those is the job, which is why the queue exists.
## Reading a match
Open any match to get the full record.
<Frame>
<img alt="The match review drawer showing the vendor, the screened subject, the flagged source, country, registration number, aliases, programmes, a field-level match breakdown, the source listing, the advisory automated read, an optional reason box, and the Confirm match, Not a match and Allowlist for 180 days buttons." />
</Frame>
Work down it in this order:
1. **Screened subject vs matched name.** The two names side by side. This is usually enough to rule out an obvious mismatch.
2. **Country and registration number.** The strongest discriminators available. A registration number that matches is close to conclusive; a country that does not match is a strong signal it is a different entity.
3. **Also known as.** Transliterations and former names. A vendor that looks unrelated in English can match exactly in its own script.
4. **Field-level match.** Which attributes agreed, and how strongly. A high overall score built only on the name is weaker than a lower score built on name *and* registration.
5. **Sources.** The listing itself. Follow it before you decide.
The **automated read** is advisory. It is there for context. Coverbase never closes a match on it; a person decides.
## Deciding
Three outcomes. The **Reason for your decision** is optional, but anything you write becomes part of the audit trail, so write it for someone reading it in a year with none of your context.
| Decision | Use it when | What happens |
| - | - | - |
| **Confirm match** | It is your vendor, and the listing is real | The match moves to **Confirmed** and its finding stays open. It is now a compliance matter, not a screening question. |
| **Not a match** | The listed record is a different party | The match closes as a false positive, and its finding is archived with your reason. |
| **Allowlist for 180 days** | It is a known, accepted match you do not want raised every cycle | Suppressed for 180 days, then re-raised for a fresh look. Its finding is archived with your reason. |
<Note>
An allowlist expires so the match gets a fresh look. Circumstances change, and a permanent suppression can leave a real listing unnoticed for years.
</Note>
With **Open a finding** on in the settings (the default), every new match opens a finding the moment it is raised, assigned to the vendor's relationship owner or risk analyst. It picks up a due date, SLA reminders and the rest of the findings workflow. Confirming leaves it open; the other two decisions archive it. A match the source stops listing moves to **No longer listed** under **Resolved** on its own. Screening raises the alert; it does not decide what you do about it, and it never blocks a payment or an onboarding on its own.
## What "clear" looks like
A vendor with nothing to review still shows its run history.
<Frame>
<img alt="The Screening tab for a vendor with no open matches, showing the history of completed screens with dates and the sources covered." />
</Frame>
<Warning>
An empty match list and a vendor that was never screened look similar and mean opposite things. Check the run history before you write "no sanctions exposure" into an assessment.
</Warning>
## Screen a vendor now, or someone it missed
**Screen now**, at the top of a vendor's Screening tab, screens everyone enrolled for that vendor straight away instead of waiting for the schedule. The page opens the result when the provider answers. If nobody is enrolled yet, it says so and nothing runs.
**People not screened** lists people named in the vendor's leadership research that screening does not cover, either because their identity could not be confirmed automatically or because no registry filing names them. **Confirm & screen** enrolls one of them for continuous screening, and **Add individual** enrolls someone the research did not find. Either records that you vouched for the person's identity, so check who they are first.
## Screen a name once
**Ad hoc screen**, on the queue, screens one name a single time without enrolling it for monitoring. Use it for a prospective supplier, a new director, or a name someone asks about.
1. Pick **Organisation** or **Person** and enter the **Legal Name** or **Full Name**.
2. Add any identifying details you have. Each one rules candidates out; a name on its own returns the most to review.
3. Check the **Sources**. They default to what your policy runs, and a source switched off for your organization cannot be picked.
4. Optionally pick a **Linked Vendor**, so the screen also shows on that vendor's record. Left empty, it stands on its own and creates no vendor.
5. Click **Run screen**. The page opens the result when the provider answers, and any match lands in the queue marked ad hoc.
An ad hoc screen raises no finding. Its matches are reviewed and decided like any other.
## Screen a vendor at intake
When someone requests a new vendor, the intake portal's pre-qualification step checks it for sanctions. An administrator sets how under **Configuration → Portal Templates**, on the intake template, under **Pre-qualifications**, below **Enable sanctions check**. Turning **Enable sanctions check** off skips the check entirely.
**Screen Against** picks the source:
* **Coverbase sanctions screening** (the default) screens the vendor with your organization's screening provider once screening is connected. The screen is recorded in the screening history, and a possible match goes to the queue marked ad hoc, like any other match.
* **OFAC list only** matches the vendor's name against the US Treasury's SDN and consolidated lists. Nothing is recorded in the screening history.
With **Coverbase sanctions screening** selected you also choose:
| Setting | Default | What it does |
| - | - | - |
| **Sources** | Sanctions | What the screen covers. A source switched off in your screening settings is skipped here too. |
| **Identity Match Threshold** | Use screening policy | How sure a match must be that a listed party is this vendor before it is raised. |
| **Include headquarters country** | On | Sends the vendor's country with its name. It narrows a common name to the right company, and can miss a listing filed under another country. |
| **Also screen suggested alternatives** | Off | Screens the alternatives intake suggests too. Each screen is billed. Off, the alternatives are checked against the OFAC list. |
What the requester sees:
* A possible match fails the sanctions check and names the listed party. Review it in the queue. A match you mark **Not a match** or allowlist no longer fails the check when the requester runs intake again.
* Until screening is enabled and connected with an API key, intake runs its standard OFAC list check, and the step works as it always has. The same happens if every chosen source is switched off, or if a screen can't complete because the provider is down or rejects the key. A failed screen still shows in the screening history, and a rejected key shows on the Screening settings page.
* If the OFAC lists themselves can't be read, the check says it needs review. It never reads as clear.
Intake runs pre-qualification again when the requester edits the request. A screen of the same vendor with the same settings in the last 24 hours is reused rather than run and billed again.
## Settings
An administrator configures screening once, under **Configuration → Monitoring → Screening**, or from **Configuration** on the queue. It needs the `integration` permission, not the screening one.
<Frame>
<img alt="The screening settings page showing the connection status, source toggles, adverse media categories, subject selection, the automation setting, the monitoring table by risk level, and the settings for a new match." />
</Frame>
The decisions that matter:
**Which sources.** Sanctions, PEP, criminal and legal are on by default. Adverse media is off, and should stay off until the rest is running cleanly. It is the highest-volume and lowest-precision source, and it will dominate your queue. When you do turn it on, keep the category list narrow.
**Who gets screened.** The vendor's legal entity is screened by default. Directors, officers and beneficial owners are opt-in, because screening a person means storing watchlist assertions about a named individual. Turn them on only when you need them. Under **Automation**, **Screen a vendor when its intelligence refresh completes** screens as soon as a refresh has established the vendor's leadership instead of waiting for the nightly sweep. It is off by default, because every refresh then costs a screen per subject.
**Which risk levels are monitored.** Monitoring is set per risk level: the vendor's residual risk level where your organization tracks residual risk, otherwise its inherent level. A monitored vendor is re-screened on a schedule and raises an alert when a source changes.
<Frame>
<img alt="The monitoring table listing each risk level, plus Not scored, with a monitored switch and a provider profile group that defaults to the workspace default." />
</Frame>
Nothing is monitored until you switch a level on, and vendors with no risk score sit in their own **Not scored** row, so switching screening on does not enroll your entire long tail. A monitored vendor is a standing subscription, not a one-off charge. The table lists your risk scale's levels, so set up the scale under Scoring first.
<Note>
**How often** each source is re-screened is set by the provider profile group, not in Coverbase. Coverbase decides *who* is monitored; the group decides *how often*. If you need a tighter or looser schedule for a risk level, set up a profile group with your provider and pick it in the table. **Workspace default** uses the provider's default.
</Note>
**What a new match raises.** Under **On a new match**, **Open a finding** and **Notify the vendor's owners** are on by default. **Assign the review to** picks the vendor's **Relationship owner** or **Risk analyst**, or **Specific person** to send every match to one named reviewer, such as a central TPRM analyst. A vendor with nobody in the chosen role falls back to the other, so no match sits unowned. If the chosen person is later deactivated, matches go to the vendor's relationship owner, then its risk analyst, and the page shows a warning until you choose someone else.
**The match threshold.** The identity match threshold is 0.80 by default and shows as **Match threshold** on each vendor's Screening tab. This page does not change it. An ad hoc screen can set its own **Match Threshold** for that one screen: lower it and you will see more true matches and many more false ones; raise it and you risk missing a real listing on thin data.
<Note>
A source switched off at the top level never runs, whatever the monitoring table says. One switch turns a source off everywhere, rather than making you clear a row per risk level.
</Note>
## Who can do what
Screening has its own permission, separate from the vendor record, so the person who reviews matches need not be the person who administers vendors.
| Permission | Allows |
| - | - |
| `screening_match:read` | See the queue, the vendor tab, and match detail |
| `screening_match:update` | Confirm, dismiss or allowlist a match; screen a vendor now; enroll a person; run an ad hoc screen |
| `integration:read` / `integration:update` | See and change the screening configuration |
There is no create or delete. Matches come from the provider and are closed by decision, never removed.
## Troubleshooting
| Symptom | Fix |
| - | - |
| The Screening tab says screening is not turned on | An administrator adds the API key and switches on **Screen vendors on a schedule** under **Configuration → Monitoring → Screening**. |
| A vendor you expected to be monitored has no recent screens | Check the vendor's risk level, and that the level is switched on under **Who is monitored**. A vendor with no risk score is under **Not scored**. |
| **Screen now** says nobody is enrolled | The settings screen nobody for this vendor. Check **Who we screen**. |
| A director named on the People tab is not screened | Directors and officers are opt-in, and only people a registry filing names are enrolled automatically. Use **Confirm & screen** under **People not screened**. |
| A dismissed match is back | An allowlist lasts 180 days, then the match is raised again for a fresh look. A match you marked **Not a match** stays closed. |
## Related
<CardGroup>
<Card title="Screening coverage and sources" icon="list" href="/user-guides/screening-coverage">
Every sanctions list, PEP role and adverse media category, and the options Coverbase configures on request.
</Card>
<Card title="Corporate registrations guide" icon="building-columns" href="/user-guides/corporate-registrations">
The legal entity that is screened.
</Card>
<Card title="People intelligence guide" icon="users" href="/user-guides/people-intelligence">
The directors and officers who can be screened alongside it.
</Card>
<Card title="Zero Touch Assessments" icon="bolt" href="/user-guides/zero-touch-assessments">
Open watchlist matches as an input to the score.
</Card>
<Card title="Dark web monitoring guide" icon="mask" href="/user-guides/dark-web-monitoring">
The neighboring Vendor Intelligence tab: leak sites, breach catalogs, infostealer logs and lookalike domains.
</Card>
</CardGroup>
# Screening coverage and sources
Source: https://docs.coverbase.com/user-guides/screening-coverage
Every source Coverbase Screening checks: the sanctions and watchlists, the PEP roles in scope, criminal and legal records, adverse media categories, monitoring cadence, and the options Coverbase configures on request.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is the reference for what [Coverbase Screening](/products/coverbase-screening) checks. For reading and deciding a match, and for the settings page, see the [Sanctions screening guide](/user-guides/sanctions-screening).
</Info>
The mistake people most often make is reading an empty match list as "screened against everything". A screen only covers the sources switched on for your organization when it ran. Adverse media is off by default, and people are only screened if you opt them in. Each run in a vendor's history lists the sources it covered, so check them before you write "no sanctions exposure" into an assessment.
## The five sources
| Source | What it covers | Default |
| - | - | - |
| [Sanctions](#sanctions-and-watchlists) | Government sanctions and designation lists, plus FATF jurisdiction ratings | On |
| [PEP](#politically-exposed-persons) | Politically exposed persons, and their relatives and close associates | On |
| [Criminal](#criminal-and-legal) | Law enforcement and terror watchlists, and records of criminal charges | On |
| [Legal](#criminal-and-legal) | Civil and criminal litigation, lawsuits and judgments | On |
| [Adverse media](#adverse-media) | Negative news, scored against the risk categories you choose | Off |
An administrator switches sources on and off under **Configuration → Monitoring → Screening**, in **What we screen against**. A source switched off there never runs: not on the schedule, not at intake, and not in an ad hoc screen.
## Sanctions and watchlists
A sanctions match means the subject appears to be named on a list of individuals or entities whose assets are frozen, who are barred from certain transactions, or who are otherwise restricted. Sanctions lists are refreshed from their sources at least daily, and the key lists as often as every six hours.
The table lists the principal sanctions and watchlist sources. The catalog changes as lists are added, so ask your Coverbase account team for the complete current list for your workspace.
### International
| List | Issued by |
| - | - |
| UN Security Council Consolidated List | United Nations Security Council |
| High risk jurisdictions (blacklist) | Financial Action Task Force (FATF) |
| Jurisdictions under increased monitoring (greylist) | Financial Action Task Force (FATF) |
The FATF lists rate the subject's country, not the subject.
### Americas
| List | Issued by |
| - | - |
| Specially Designated Nationals (SDN) List | U.S. Treasury, Office of Foreign Assets Control (OFAC) |
| Consolidated Sanctions List (Non-SDN) | U.S. Treasury, OFAC |
| Consolidated Screening List (13 lists, including the SDN, Non-SDN and BIS lists) | U.S. International Trade Administration |
| Denied Persons List | U.S. Bureau of Industry and Security (BIS) |
| Most Wanted | U.S. Federal Bureau of Investigation (FBI) |
| Hijack Suspects List | U.S. government |
| Terrorist List, including domestic terrorists | U.S. government |
| Consolidated Canadian Autonomous Sanctions List, covering the Special Economic Measures Act (SEMA), the Justice for Victims of Corrupt Foreign Officials Regulations (JVCFOR) and the Freezing Assets of Corrupt Foreign Officials Act (FACFOA) | Government of Canada |
| Listed Terrorist Entities | Public Safety Canada |
| Regulations Implementing the United Nations Resolutions on the Suppression of Terrorism (RIUNRST, SOR/2001-360) | Government of Canada |
| Public Registry of Persons and Entities linked to acts of Terrorism and its Financing (RePET) | Argentina, Ministry of Justice and Human Rights |
### Europe
| List | Issued by |
| - | - |
| Consolidated financial sanctions list | European Union, European External Action Service (EEAS) |
| Consolidated sanctions list | UK HM Treasury |
| National asset freezing list, combined with the EU and UN lists | France, Direction générale du Trésor |
| Sanctions and embargoes list (SESAM) | Switzerland, State Secretariat for Economic Affairs (SECO) |
| National Sanctions List (National Terrorist List) | Belgium, Federal Public Service Finance |
| Blacklist | Ukraine, State Financial Monitoring Service |
| List of organizations and individuals involved in terrorist activities | Belarus, State Security Committee |
| Domestic lists under UN Resolution 1373 | Central Bank of Armenia |
| Domestic list of sanctioned persons | Azerbaijan |
### Asia Pacific
| List | Issued by |
| - | - |
| Consolidated Sanctions List | Australia, Department of Foreign Affairs and Trade (DFAT) |
| Listed Terrorist Organisations | Australia, National Security |
| Domestic Sanctions List | Central Bank of Bangladesh |
<Note>
A match shows the list it came from. Follow the source link in the match before you decide it: the list entry is what tells you what the match means.
</Note>
## Politically exposed persons
A PEP is someone who holds, or held within the lookback period, a prominent public function whose role gives elevated corruption, bribery, sanctions evasion or money laundering risk. PEP data draws on public office records and sources including OpenSanctions, Rulers.org and EveryPolitician, normalized to one inclusion standard.
**In scope by default**
| Category | Includes |
| - | - |
| National government | Heads of state and government, cabinet members, national legislators, senior judges and prosecutors, central bank leadership |
| Security and diplomacy | Senior military, police and intelligence leadership, ambassadors and senior diplomats |
| Intergovernmental organizations | Senior leadership and governing officers |
| Regional government | Governors, premiers and other regional heads of government, and regional executives and legislators |
| Local government | Mayors, local executives, and council members whose role carries real authority over public funds, procurement or licensing |
| State owned enterprises and public agencies | Senior executives, board members and other senior decision makers |
| Political parties | Senior party leaders and other officials with material political influence |
| Relatives and close associates | Spouses, partners, children, parents, siblings, known business associates and nominees of a PEP, where the relationship is supported by evidence. They are classified separately from office holders. |
**Out of scope by default:** ordinary civil servants, junior staff of public agencies and state owned enterprises, administrative staff, and people who are politically adjacent but hold no qualifying office.
**How long someone stays a PEP after leaving office**
| Position | Lookback after leaving office |
| - | - |
| National and intergovernmental positions | 20 years |
| All other qualifying positions | 5 years |
The default scope is broader than some regulatory definitions. A PEP match is a reason to look, not a legal conclusion.
## Criminal and legal
**Criminal** covers law enforcement and terror watchlists, and records of criminal charges and involvement in criminal activity.
**Legal** covers involvement in civil or criminal litigation, including lawsuits and judgments. It is useful context on legal and reputational risk, and it produces more matches to review than sanctions does.
## Adverse media
Adverse media is negative news coverage that records financial crime or reputational risk that has not reached a sanctions or PEP list. Articles come from over 200,000 news outlets, broadcasters, professional journals and blogs, in more than 140 languages, and new coverage is picked up within minutes.
Each article is scored for sentiment and for the risk categories switched on for your organization. Only an article in a category you switched on raises a match.
<Warning>
Adverse media is the highest volume and lowest precision source, and it is off by default. Turn it on once the rest of screening is running cleanly, and start with a narrow category list. Every category you add lengthens the queue.
</Warning>
**Standard categories.** These are on the settings page under **Adverse media categories**. The first six are selected by default.
| Category | Covers | Default |
| - | - | - |
| **Sanctions** | Sanctions evasion, embargo breaches, or trading with designated parties | On |
| **Money laundering** | Concealing or moving suspected criminal proceeds | On |
| **Fraud, bribery & corruption** | Fraud, bribery, corruption, embezzlement, kickbacks, or abuse of position | On |
| **Terror funding** | Raising, moving or providing funds for terrorism | On |
| **Cybercrime** | Hacking, ransomware, phishing, data theft and other technology enabled crime | On |
| **Tax evasion** | Concealed income, false returns, offshore evasion, or VAT fraud | On |
| **Organised crime** | Cartel, gang, racketeering or other criminal enterprise involvement | Off |
| **Human trafficking** | Forced labor, sex trafficking, or other exploitation of people | Off |
| **Narcotics** | Production, trafficking or distribution of controlled substances | Off |
| **Smuggling** | Illegal cross border movement of goods, customs evasion, or contraband | Off |
| **Insider trading** | Trading or tipping on material non public information | Off |
| **Weapons** | Illegal arms sales, arms trafficking, or embargo violations | Off |
**Further categories, on request.** The wider catalog includes sector specific categories such as cryptocurrency, casinos, real estate, fine art, rare gems and metals, money service businesses, lending, luxury vehicles, non profits and terrorism, and non financial categories such as assault and property damage. They are not on the settings page. If your program needs one, ask your Coverbase account team.
An **Ad hoc screen** can pick its own categories and set an **Adverse Media Lookback (days)** for that one screen.
## Monitoring cadence
A monitored vendor is re-screened on a cadence set per source.
| Source | Default cadence |
| - | - |
| Sanctions | Daily |
| PEP | Monthly |
| Adverse media | Monthly |
The available cadences are daily, weekly, monthly, quarterly, twice a year and annually. Sanctions can also be re-screened whenever a monitored list publishes a change. A cadence can never be more frequent than the cap for your workspace, which by default matches the cadences above.
Coverbase decides who is monitored; the cadence comes from the profile group a risk level is assigned to. To monitor one risk level more or less often than the default, ask your Coverbase account team to set up a profile group with that cadence, then pick it for the risk level in the monitoring table on the settings page. The [settings section of the screening guide](/user-guides/sanctions-screening#settings) shows where.
## Options Coverbase configures on request
These are set up by Coverbase for your workspace, not on the settings page. Some carry an additional charge. Contact your Coverbase account team or [support@coverbase.ai](mailto:support@coverbase.ai).
| Option | What it does |
| - | - |
| **Monitoring cadence by risk level** | A profile group with its own cadence, so critical vendors can be screened more often than the rest. See [Monitoring cadence](#monitoring-cadence). |
| **Further adverse media categories** | Categories from the wider catalog beyond the standard 12. |
| **Custom lists** | Your own internal watchlists, such as a do not onboard list, screened alongside the standard sources. Matches appear under the source you choose, with the list name as their source. Enterprise plans only. |
| **Match scoring** | How heavily each identifying detail (name, country, registration number, date of birth) counts toward the identity confidence score. |
| **Repeated alert suppression** | Whether a monitored vendor that matches the same record again is raised again. A balanced setting is on by default, so a materially new listing is always raised. |
| **Name mention filtering for adverse media** | Labels or filters articles that only mention a similar name rather than involving the subject. |
Changes to scoring and suppression change what reaches your queue, so agree them with your compliance owner before asking for them.
## What screening does not cover
Some outside-in checks live elsewhere in Coverbase:
| You want | Where it is |
| - | - |
| Whether the company is legally registered and active | [Corporate registrations](/user-guides/corporate-registrations) |
| Who runs the vendor, and news about those people | [People intelligence](/user-guides/people-intelligence) |
| Breaches, regulator actions and news events about a vendor | [Radar signals](/user-guides/radar-signals) |
| Leaked credentials and lookalike domains | [Dark web monitoring](/user-guides/dark-web-monitoring) |
## Troubleshooting
| Symptom | Fix |
| - | - |
| A run in a vendor's history does not list adverse media | Adverse media is off for your organization. An administrator turns it on under **What we screen against**. |
| A news story about a vendor did not raise a match | Check that its category is switched on under **Adverse media categories**. An article only raises a match in a category you selected. |
| You need a list that is not in this catalog | Ask your Coverbase account team. The catalog is a summary, and some lists can be added as a custom list. |
| You need sanctions checked more often for some vendors | Ask Coverbase for a profile group with a tighter cadence, then pick it for that risk level. |
| An ad hoc screen will not let you pick a source | The source is switched off for your organization. A source switched off in the settings cannot be picked anywhere. |
## Related
<CardGroup>
<Card title="Coverbase Screening" icon="scale-balanced" href="/products/coverbase-screening">
What screening does, and how it fits into intake and monitoring.
</Card>
<Card title="Sanctions screening guide" icon="scale-balanced" href="/user-guides/sanctions-screening">
Reading a match, deciding it, and configuring the policy.
</Card>
<Card title="People intelligence guide" icon="users" href="/user-guides/people-intelligence">
The directors and officers who can be screened alongside the vendor.
</Card>
<Card title="Corporate registrations guide" icon="building-columns" href="/user-guides/corporate-registrations">
The legal entity and registration number a screen is matched on.
</Card>
</CardGroup>
# Security intelligence guide
Source: https://docs.coverbase.com/user-guides/security-intelligence
How to read a vendor's outside-in security rating, what each factor measures, and what a not-measured factor does and does not tell you.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For what the capability is and where it stops, see [Security intelligence](/products/security-intelligence).
</Info>
This page rates a vendor's internet-facing security from the outside, by querying their own infrastructure. Nobody at the vendor is contacted, and nothing here depends on their cooperation.
## Finding it
Open a vendor, go to **Vendor Intelligence**, and pick the **Security** tab.
The buttons at the top read, left to right, **Refresh**, **Generate findings**, **Export PDF** and the actions menu (**...**). Hover over **Refresh** to see when the page was last refreshed and who or what started it. **Export assets**, a spreadsheet of every asset the scan found, is in the actions menu. When the window is too narrow, **Generate findings** and **Export PDF** move into the actions menu as well.
<Frame>
<img alt="The Security tab for a vendor, with Refresh, Generate findings, Export PDF and the actions menu at the top, an overall rating of 78 with a verdict naming email authentication as the factor costing points and a Scan a different domain button, a row of jump links to each section, Next steps and Since last scan side by side, and the score breakdown with email authentication expanded to its three findings." />
</Frame>
The page is laid out in the order a review runs. The rating comes first, then **Next steps** and **Since last scan** side by side, then the score breakdown and the evidence sections behind it. A row of jump links under the rating takes you to any section without scrolling. It lists only the sections this scan produced, so a vendor with no known vulnerabilities is not offered a link to an empty heading.
## The summary above the rating
A short summary sits above the rating: what is in good shape, the key gaps, and the checks that could not be measured.
<Frame>
<img alt="The Security posture report for a vendor. An Analyst revised badge reads Scanned at 78, revised to 81 by your team. Three columns follow: What's in good shape lists five factors graded A, Key gaps lists an actively exploited vulnerability, DMARC not enforcing and a mail-capable lookalike domain, and Checks still open says domain squatting could not be measured. The rating card and Next steps sit below." />
</Frame>
## Revising the page
The scan reads what is public, and it can be wrong about a particular vendor. A vulnerability can match a host the vendor no longer runs, or a finding can belong to someone else's infrastructure. **Revise from notes or evidence** corrects the page from text you paste, without changing the shared research.
<Steps>
<Step title="Paste what you know">
Open the actions menu (**...**) and pick **Revise from notes or evidence**. Paste analyst notes, evidence the vendor sent, or a plain correction, then click **Propose changes**.
</Step>
<Step title="Review each proposed change">
Each change shows the old value, the new one, why, how confident it is, and the words from your text it rests on. Untick any you do not want. The preview on the right shows the rating and grade the changes you keep would leave.
<Frame>
<img alt="The Revise Security Posture dialog. One change is accepted: vulnerability CVE-2026-10233 moves from Active to Dismissed, with the rationale that OpenSSH is not exposed on the vendor estate and a quote saying the host was decommissioned in March. The score preview takes the security rating from 78 to 81, grade B." />
</Frame>
</Step>
<Step title="Apply">
Applying saves a new version. The report shows an **Analyst revised** badge with the scanned and revised ratings.
</Step>
</Steps>
On this page you can dismiss a finding or a vulnerability that is not about this vendor. Your text is read as evidence, not as instructions. A change needs support in what you pasted, and anything that reads as an instruction to the product is set aside.
To have Coverbase do this check for you, pick **Check against the vendor's own pages** from the same menu. It reads the vendor's own website and the public record behind each item. A CVE or finding it can show is about a different company, quoting the page or record that shows it, is dismissed as a new version labeled **Automated review**. Read it and restore the previous version if you disagree. The same check runs on its own after every Zero Touch run.
A revision applies to your organization only. Other organizations that monitor the same vendor still see the scan as it ran. When the vendor is rescanned, your accepted changes are carried onto the new scan, and a change whose finding no longer appears falls away.
### Your team's revisions
**Your team's revisions**, at the end of the page, lists each change with its reason and quote, then every version of the page. **Restore** makes an earlier version current again. A restore is itself a new version, so nothing in between is lost. Version 1 is always the page as scanned.
<Frame>
<img alt="The Your team's revisions section: a dismissed vulnerability CVE-2026-10233 with its rationale and a quoted line from the analyst's notes, then Version 2, an analyst revision marked Current, and Version 1, the pipeline scan, with a Restore button." />
</Frame>
## Next steps
<Frame>
<img alt="Two panels side by side. Next steps lists four ranked actions: an actively exploited vulnerability marked Urgent, DMARC not enforcing and a mail-capable lookalike domain marked Soon, and findings open for six months or more on two assets marked Routine, each with Ask the vendor and Go to controls. Since last scan shows the score moving from 77 to 78, two factor moves, one new finding, one resolved finding, one new vulnerability, one new asset and one asset no longer seen." />
</Frame>
**Next steps** turns the scan into a short list of things to do, most urgent first. Each step names the evidence it rests on, says in one line why it matters, and offers two actions:
* **Ask the vendor** copies a question ready to paste into a message. It quotes the observed value, so the vendor gets a specific, checkable claim rather than a request to investigate.
* **Go to** scrolls to the section holding the evidence.
Steps are ranked **Urgent**, **Soon** or **Routine**. Urgent means something attackers are using now: a vulnerability on CISA's Known Exploited Vulnerabilities list, a CVE tied to ransomware campaigns, a database or remote-desktop port open to the internet, or a failing certificate. Soon covers policy gaps a vendor can fix in a change window: DMARC that does not enforce, a permissive SPF record, legacy TLS, a certificate expiring within three weeks, a mail-capable lookalike domain, or staff credentials exposed in a breach in the last year. Routine covers the things that make the rating itself more trustworthy: findings open for six months or more, an estate nobody has reviewed, and a rating that rests on a minority of the model because a scanner had no credential.
Every step is a rule on the scan data, not a judgment call. The same vendor produces the same list in a report or through MCP, and a list that reads **Nothing in this scan needs action** means every rule came back clear. It does not mean the vendor is secure. See [the rating is a floor, not a verdict](#the-rating-is-a-floor-not-a-verdict).
<Tip>
Copy the question before you open a finding. The remediation step on the finding tells the vendor what to change; the question tells them what you saw and asks for a date. Sending both closes the loop in one message.
</Tip>
## Since last scan
**Since last scan** compares this scan with the previous one and lists what moved: the score, each factor that changed, findings that appeared or were resolved, vulnerabilities that appeared or are no longer observed, and assets that arrived or left the estate. Each count opens to the names behind it.
<Frame>
<img alt="The Since last scan panel compared with the scan on Jul 1, 2026, showing the score moving from 77 to 78, Web application headers falling from 76 to 71, TLS configuration rising from 84 to 96, one new finding opened to show a cookie not marked Secure, and one resolved finding opened to show an obsolete TLS version on a departed host." />
</Frame>
Read it before the factors when you are returning to a vendor you already know. A rating that dropped six points because one factor slipped is a different conversation from one that dropped six points because a new host appeared with an expired certificate, and the panel tells you which in two lines.
Three states look similar and are not:
* **No earlier scan to compare with yet** means there is nothing to compare against: a first scan, or a profile stored before the comparison existed. Changes appear after the next refresh.
* **Nothing changed** means the scan ran and found the same findings, assets and score as before.
* A panel with counts means something moved, and the factor rows in the score breakdown carry the same movement as a small badge.
A finding counts as resolved only when its factor was measured in both scans. A source that was skipped this time has not fixed anything, so its findings are left out of the comparison rather than reported as resolved.
A second refresh on the same day keeps comparing against the earlier day rather than against the morning's scan, so running a refresh by hand after the scheduled one does not wipe the panel. Each count is the full number that moved. For a vendor whose estate holds more than 250 assets, the panel reports assets that left but not assets that arrived, because the stored estate is capped and cannot serve as a complete baseline.
## Standing among your vendors
When your organization has at least five vendors with a security rating, the rating carries a standing such as **Top 30%** or **Bottom 20%**. It is the share of the other rated vendors you can open that this one scores at or above, computed when you open the page from the ratings as they stand today. Hover it for the count. A user who can only open assigned vendors is ranked among those vendors, so two people can see different standings for the same vendor.
It ranks the vendor against your portfolio, not against the industry. A vendor in your top 10% can still carry an actively exploited vulnerability, which is why **Next steps** sits above it in the reading order. To see the vendor against its own market, read [Compared with industry peers](#compared-with-industry-peers).
## Compared with industry peers
A rating on its own does not tell you whether a 72 is weak for this kind of company or typical of it. **Industry Comparison** places the vendor beside three to seven companies that sell what it sells, each rated by the same scan.
<Frame>
<img alt="The Industry Comparison section. A radar chart titled Rating by Factor draws Northwind Data as a filled green shape against a dashed blue industry average across ten factors. Beside it, Northwind Data scores 78 (Strong), the industry average is 76 (Strong) and the rank is 4 of 6, with a line reading 2 points above the industry average of 76, then Leads peers on TLS configuration and Trails peers on Email authentication. Below, Peer Comparison shows a highlighted tile for Northwind Data at 78 and tiles for six peers with their scores and bands, one still scanning." />
</Frame>
The section has three parts:
* **Rating by Factor** draws the vendor's factor scores as a filled shape and the industry average as a dashed outline. Where the fill falls inside the outline, the vendor trails its peers on that factor.
* The summary gives the vendor's rating, the industry average and the vendor's rank, then the factor the vendor leads its peers on by the most and the one it trails on by the most.
* **Peer Comparison** gives each company's rating with its band: Critical, Weak, Fair, Strong or Advanced. The vendor's tile comes first and is highlighted. Hover a tile to see why the company was chosen and when it was last scanned.
Once three peers have a rating, the same comparison appears in brief in the top right of the rating card: the industry average, where the vendor ranks, and every rated company on a strip of the rating scale. **See comparison** jumps to the full section. In **Vendor Intelligence**, the **External Security Intelligence** card on the **Overview** tab repeats the average and the rank in one line.
<Frame>
<img alt="The rating card. On the left, a security rating of 78 (Strong) on the rating scale. In the top right, Industry Peers: an industry average of 76, a line reading Northwind Data is 2 points above it, Ranks 4 of 6, and a strip of the rating scale with a dot for each rated peer and a ring for the vendor, then a See comparison link." />
</Frame>
### How peers are chosen
Peers are chosen for the product your organization buys from the vendor. Coverbase reads the vendor's services and product list in your workspace, or its use case when neither names a product, and compares the vendor at company level when there is neither. It searches the web for the vendor's competitors, adds the competitors already on the vendor's fact sheet, and has a model pick the closest companies: ones that sell a competing product to the same kind of buyer, in the same industry, at a comparable scale.
The picks are then checked. A company is dropped when the only website found for it is a profile on another site, such as LinkedIn or a review site, when it is the vendor itself, its parent or its owner, or when it repeats a company already on the list.
Coverbase keeps between three and seven peers. When the first pick leaves fewer than three, it asks for more, and when it still cannot find three, it shows no comparison rather than one built on one or two companies.
Each peer is rated by the same outside-in scan as your vendors. A peer Coverbase already rated in the last 30 days keeps that rating. A new peer, or one with an older rating, is scanned when the comparison is built, and its tile reads **Scanning** until the result lands, usually within a few minutes. A company the scan cannot measure reads **Not rated** and is left out of the average. When that leaves fewer than three rated peers, Coverbase replaces the companies it could not rate.
### Keeping it current
The comparison is built the first time anyone opens the vendor's Security tab, and then keeps itself current:
* Peers are chosen again every 90 days.
* A peer's rating is refreshed once it is more than 30 days old.
To choose peers again sooner, for example after the vendor changes what it sells, click **Choose peers again** in the section header. You need permission to edit the vendor, and peers can be chosen again at most once an hour.
Peers and their ratings are shared research. Every organization that buys the same product from the same company sees the same peers, and a peer's rating is the same wherever it appears. Your organization's revisions to this vendor's rating carry into the comparison, because it compares the rating you see.
### Reading the comparison
* The industry average is the mean of the rated peers' overall ratings, and it appears once at least three peers have a rating. On the chart, each factor is the mean of the peers that measured it, and a factor is drawn only when the vendor and at least two peers were measured on it.
* A note under the summary says when some peers were rated on fewer factors than the vendor. Their overall scores weigh fewer checks, so they compare less directly.
* The comparison is outside-in, like the rest of the page. A vendor above its industry average can still carry an actively exploited vulnerability, so read **Next steps** first.
**Export PDF** includes the comparison: the chart with the figures beside it, then a tile for every company.
## The rating is a floor, not a verdict
Everything measured here is visible from the public internet. That is both its strength and its limit.
A strong rating means the things an attacker can see from outside are in order. It says nothing about what happens inside the vendor's network, how they manage access, or whether they have a working incident process. Those questions need an assessment.
A weak rating is more actionable in the other direction. A monitor-only DMARC policy or an expired certificate is a fact, not an inference, and you can raise it with the vendor immediately.
## Scan the right domain
The rating measures one domain, taken from the vendor's website on file. The chip under the rating names it. If that is a marketing host, a redirect or another company's domain, click **Scan a different domain** beside the verdict. Enter a host or a full URL, or pick one of the hosts the scan already attributes to the vendor, and click **Rescan**.
The rating updates when the new scan finishes, and later refreshes keep scanning the domain you chose. Unlike a revision, this changes the shared research, so every organization that monitors the same company is rated on the new domain. You need permission to edit the vendor.
## Read the factors, then the number
The overall rating is a weighted roll-up. The factor breakdown underneath it is what you act on.
Each factor expands to show the specific observations behind its score, so a low number always resolves to something concrete: a hostname, a header, a certificate, a CVE.
<Warning>
A factor marked **not measured** was excluded from the rating. It is not evidence that the control is in place, and it is not evidence that it is missing. It means we could not observe it.
</Warning>
That distinction matters when you are writing up an assessment. "Not measured" belongs in the questions you ask the vendor, not in the findings you record against them.
## Open a finding to get the fix
Click any finding in a factor to open it.
<Frame>
<img alt="A panel titled DMARC reports forged mail but still delivers it, marked High, with Impacts rating Yes minus 24, first and last seen dates, an observed value of p=none, a remediation step, and a Raise finding button." />
</Frame>
The panel answers the four questions you need before you can raise it with anyone:
* **Impacts rating** tells you whether this finding cost points, and how many. A finding recorded for completeness that moved nothing says **No**.
* **First seen** and **Last seen** tell you how long it has been open. A finding that has survived months has been seen by the vendor's own team too.
* **Observed** is the raw value the scan read, such as `p=none` or `TLSv1.0`.
* **Remediation** is the step that resolves it, written for whoever operates the asset rather than for you.
When you forward a finding to a vendor, "TLS 1.0 is enabled" on its own gives them a problem to research. The remediation step means they can act on it without a round trip.
## Raise findings from what the scan found
**Raise finding** on an open finding creates a tracked finding against the vendor, pre-filled with the asset, the observed value and the scan date, so it stands on its own once it leaves Coverbase.
When a sweep turns up the same problem across a dozen hosts, use **Generate findings** at the top of the page instead.
<Frame>
<img alt="A dialog titled Generate Findings for Northwind Data listing eight scored issues with severity badges, each with a checkbox, and a Generate 8 findings button." />
</Frame>
Only issues that cost the rating points are listed, because a zero-penalty observation is not something a provider needs to action. Untick anything the provider already owns before you generate.
## Rating over time
Each point is a restatement of the whole rating. A step change usually means a scan found something new rather than the vendor changing overnight, so read the factors before drawing a trend.
The history lives in the drawer at the bottom of the page, beside the **Security timeline**: every dated fact on the profile in one list, newest first. Each rating, the day each open finding was first seen, each breach, each asset that appeared or was no longer seen, and each disclosed incident. Use it to see that a breach, a new host and a rating drop landed in the same fortnight without opening four sections.
## Attack surface
What is reachable from the internet under the vendor's domains: hosts, exposed services and open ports. A large surface is not automatically a finding; it is context for the rest of the page.
Transport checks run per host rather than only against the vendor's main domain, so a neglected server is not hidden by a well-configured main domain.
<Frame>
<img alt="A certificates-by-host table listing two hosts with their trusted-chain status, negotiated protocol, days to expiry and issuer." />
</Frame>
## Attributed estate
The scan works out which domains and addresses belong to the vendor from certificate transparency logs and public scan data, then measures each one. **Attributed Estate** is that list, and it is where you correct what the scan got wrong.
<Frame>
<img alt="A table titled Attributed Estate listing nine domains and addresses with status badges reading Unreviewed, Confirmed and Disputed, plus first and last seen dates and a row actions menu." />
</Frame>
Attribution is worked out from domain names, so two kinds of mistake are normal and both are yours to fix.
### Something is listed that is not theirs
Shared hosting, a reseller, or a product the vendor buys rather than runs. Open the row's actions menu and choose **Dispute**. The next scan skips that asset entirely, and its findings leave the rating.
Choose **Confirm** when you have checked an asset and it is theirs. That records the decision so nobody re-reviews it, and it does not change the rating.
### Something they run is missing
The scan only finds hosts that appear in a public certificate, so an internal host, or one the vendor never published a certificate for, never shows up on its own.
<Frame>
<img alt="A dialog titled Add Assets with a Hostnames or IP addresses box holding three entries on separate lines and an Add 3 and rescan button." />
</Frame>
Click **Add asset**, then enter the hostnames or IP addresses, one per line or separated by commas. The next scan probes and scores them like any other asset. Assets you added are marked **Added by hand** and survive a scan that cannot see them, because they are your assertion rather than an observation.
Add the whole list in one go rather than one at a time. Each submission starts a single rescan covering everything in it, so ten hosts added together cost one scan, where ten separate additions cost ten.
If a line is not a hostname or an IP address, the rest are still added. The dialog stays open holding only the lines that failed, so you fix those rather than retyping the list. A mistyped address such as `999.1.1.1` is rejected rather than accepted as a hostname. Accepting it would put an asset in the estate that can never resolve.
<Note>
Disputing an asset starts a rescan, and so does withdrawing a dispute. A verdict only reaches the rating once the scan has run again, and withdrawing one is what puts the asset back into the score.
</Note>
Each row carries when the asset was first and last seen. An asset the scan can no longer find is kept and marked **No longer seen** rather than deleted, because an asset leaving the estate is as worth knowing about as one arriving.
## Email authentication
SPF, DKIM and DMARC as published. What matters is the policy, not the presence of a record: a DMARC record set to `none` monitors and enforces nothing, and an SPF record ending in `+all` authorizes the entire internet to send as that domain.
## Web hardening
Transport and browser-facing protections on the vendor's public sites: TLS configuration and the security headers a browser acts on.
## Breaches and exposed credentials
Known breach records and credential exposures associated with the vendor's domains, with dates. Age matters: a decade-old breach and one from last quarter are different conversations. To have new ones found daily and triaged, see [Dark web monitoring](/user-guides/dark-web-monitoring).
## Reputation and blocklists
Whether the vendor's domains or hosts appear on public blocklists or threat feeds.
## Security disclosures
Whether the vendor publishes a vulnerability disclosure policy or security contact. Its absence is a maturity signal, not a vulnerability.
## What was scanned
Which checks ran, when, and which did not resolve. A factor that could not be scanned is reported as such rather than scored as a pass.
## Known vulnerabilities
Vulnerabilities are matched against software observed on the vendor's estate, and ordered by how likely they are to be exploited rather than by severity alone.
A vulnerability on CISA's Known Exploited Vulnerabilities list is called out separately. Those are being exploited now. Raise them with the vendor the same week rather than noting them in a report.
## Lookalike domains
The page lists domains built to resemble the vendor's own, and marks which of them resolve and which can receive mail. To have new ones found daily and triaged, see [Dark web monitoring](/user-guides/dark-web-monitoring).
A mail-capable lookalike matters most. It can host a page and receive replies, which is what a supplier-invoice fraud attempt against you needs.
## Troubleshooting
| Symptom | Fix |
| - | - |
| The page says not yet scanned | The vendor has no website on file, or the first scan has not run. Add a website if it is missing. |
| The rating is for the wrong domain | Click **Scan a different domain** beside the verdict and point the scan at the vendor's real domain. |
| The whole page describes a different company | Open the actions menu (**...**), pick **Correct the AI**, choose **This is a different company**, and say why under **What should the model know?**. Give the right website if you know it. The tab is researched again straight away. |
| The rating moved and nothing looks different | Open the rating history. Certificates expire and DMARC records change without anyone announcing it. |
| The rating on the card differs from the revised rating | The card shows the scan. The **Analyst revised** badge shows the rating after your team's accepted changes, and **Your team's revisions** lists them. |
| A factor shows no findings but a low score | Expand it. Some factors score on configuration rather than on discrete findings. |
| A vulnerability looks wrong | Version detection is remote and imperfect. Check the flagged component with the vendor before recording it. |
| An asset in the estate is not the vendor's | Dispute it from the row's actions menu. The next scan drops it from the sweep and from the rating. |
| A host you know about is not in the estate | It has no public certificate, so discovery cannot see it. Use **Add asset**, and add every missing host in the same submission so they share one rescan. |
| A dispute has not changed the rating yet | The rescan it started has to finish first. The rating moves on the next completed scan, not on the click. |
| A line was refused when you added assets | It did not read as a hostname or an IP address. The rest were still added, and the dialog keeps the refused lines so you can correct them. |
| Next steps says nothing needs action but a factor scored D | The factor's findings did not trip a rule. Open the factor: a low score built from several small deductions is worth raising, and each finding still has a remediation step and **Raise finding**. |
| Since last scan says no earlier scan, but the vendor has been scanned for months | The comparison is stored by each scan against the one before it. A profile written before the comparison existed has nothing to compare with until the next refresh runs. |
| The standing pill is missing | Your organization has fewer than five vendors with a security rating, or this vendor has no rating yet. |
| Industry Comparison says Coverbase could not find at least three companies | Coverbase could not identify three companies that sell what the vendor sells. Add the product you buy as a service on the vendor, then click **Try again**. |
| Industry Comparison shows the tiles but no average | Fewer than three peers have a rating. Wait for the scans marked **Scanning** to finish. If the section says too few could be rated, Coverbase replaces the companies it could not measure, or you can click **Choose peers again**. |
| The peers are for a different product than the one you buy | Peers follow the vendor's services and product list in your workspace. Correct those, then click **Choose peers again**. |
| A peer reads Not rated | The scan could not measure that company's domain, so it is left out of the average. The scan is tried again on a later visit. |
| A finding shows as resolved but the vendor changed nothing | Check the drawer's scan coverage. A source that was skipped this time drops its findings from the comparison, and the rating; they return when the source runs again. |
## Related
<CardGroup>
<Card title="Financial health guide" icon="chart-line" href="/user-guides/financial-health-score">
The other outside-in score on the same vendor.
</Card>
<Card title="Zero Touch Assessments" icon="bolt" href="/user-guides/zero-touch-assessments">
Security posture as a scored component.
</Card>
</CardGroup>
# ServiceNow workflow actions
Source: https://docs.coverbase.com/user-guides/servicenow-workflow-actions
Write to your ServiceNow instance from a Coverbase workflow: create and update linked records, create one record per issue or finding, send a custom request, upload documents, and read what each step sent.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **ServiceNow record** actions in the workflow editor. It sits beside [Building a workflow](/user-guides/building-a-workflow), which covers triggers, conditions, placeholders and the runs page, and [Workflow templates](/user-guides/workflow-templates). For what the ServiceNow integration does as a whole, and how the connection is provisioned, see the [ServiceNow integration guide](/integrations/guides/servicenow).
</Info>
<Note>
Workflows is an optional module. If you do not see **Workflows** in the left navigation, ask your Coverbase account team to turn it on.
</Note>
A workflow can write to your ServiceNow instance as one of its steps. When an assessment finishes, it can open a Vendor Risk Management assessment record, file one risk issue per finding, attach the vendor's evidence, and close the record when everything has landed. Each of those is an automation whose **Then** is one of five actions in the **ServiceNow record** group, and each step records the request it sent and the response ServiceNow gave.
The mistake people make most often is using **Create** where they need **Update**. **Create** writes one record per Coverbase record and table. Every later run of it for the same Coverbase record is **Skipped**, because a record is already linked, so a change you want to push afterwards needs an **Update** step.
## Before you start
**The connection.** The actions write through your organization's ServiceNow connection, which is set on the **ServiceNow GRC** card under **Configuration** → **External Integrations**: the **ServiceNow base URL**, then **Basic authentication** or **OAuth 2.0 (client credentials)**. Click **Save ServiceNow Configuration** first. **Test connection** only checks saved credentials, so it stays unavailable while the form has unsaved changes. The account behind the connection needs write access to every table your steps write to, and to attachments if you upload documents. Provisioning is covered in [Authentication and provisioning](/integrations/guides/servicenow#authentication-and-provisioning). Saving the connection needs the role that manages integrations, by default an Admin.
**Where the actions appear.** While Coverbase knows the connection is not saved, the action picker hides the **ServiceNow record** group. If you cannot read integration settings, the group stays visible, and a step that runs without a connection is **Skipped** with "ServiceNow integration is not configured".
**ServiceNow IDs.** A ServiceNow reference column stores the `sys_id` of the record it points at. Coverbase holds a vendor's, service's or assessment's `sys_id` as its external ID when the record came in from ServiceNow or through the [Import API](/import-api), and the **Insert variable** menu offers it as **External ID (ServiceNow sys\_id)** (`{{vendor:external_id}}`, `{{service:external_id}}`, `{{assessment:external_id}}`). A record without one skips any step that uses the variable. A `sys_id` you keep in a custom field works the same way, through that field's entry in the menu.
Building the automation itself needs the workflow permissions described in [Building a workflow](/user-guides/building-a-workflow#who-can-do-what).
## The five actions
Open an automation, click the action under **Then**, and hover **ServiceNow record**, or type "ServiceNow" into **Search actions...**.
<Frame>
<img alt="The Coverbase workflow action picker open on the ServiceNow record group, showing Create, Create one per issue or finding, Send custom request, Update and Upload documents" />
</Frame>
| Action | What it does | What it raises |
| - | - | - |
| **Create** | Creates one record in a table and links it to a Coverbase record from the trigger. | **Service Now Record Created** |
| **Update** | Updates the record an earlier **Create** linked to the same Coverbase record. | **Service Now Record Updated** |
| **Create one per issue or finding** | Creates one record for each issue on the triggering assessment, or for each finding attached to it. | **Service Now Record Created** per record, then **Service Now Sync Completed** |
| **Send custom request** | Sends one `POST`, `PATCH` or `PUT` with a JSON body you write, to any API path on your instance. | Nothing |
| **Upload documents** | Uploads Coverbase documents into ServiceNow Document Management. | **Service Now Record Created** per document |
**Create one per issue or finding** is offered only when the trigger can reach an assessment; its form shows **Reads:** **Assessment**. The events in the last column can trigger later automations, and your own systems can receive them as webhooks (`ServiceNowRecord.Created`, `ServiceNowSync.Completed` and so on); see [Webhooks](/user-guides/webhooks).
## Mapping fields
**Create**, **Update** and **Create one per issue or finding** share the same two settings: the table, and the field mappings that become the record.
**ServiceNow table.** Pick a table from the list, or type any table name and choose **Use custom name**. The list suggests the standard third-party risk tables:
| Suggested table | Name in ServiceNow |
| - | - |
| Third Party (Vendor) | `core_company` |
| Engagement | `sn_vdr_risk_asmt_vendor_engagement` |
| External Assessment (VRA) | `sn_vdr_risk_asmt_assessment` |
| Third-party Risk Issue | `sn_vdr_risk_asmt_issue` |
| Document (Document Management) | `ds_document` |
| Document version (Document Management) | `ds_document_version` |
**Field mappings.** Each row pairs a **ServiceNow field** with a **Value**. The field picker suggests the standard columns of a suggested table. For any other column, including your instance's own `u_` columns, type the column name and choose **Use custom name**. A value can be fixed text, a variable from the **Insert variable** button beside it, or both, as in `{{vendor:name}} renewal`. **Add mapping** adds a row. Each column can appear once, and a step needs at least one row.
**Translating a value.** A row's **Coverbase value** to **ServiceNow value** pairs are listed under it, and the arrows button adds them to a row that has none. After the value's variables resolve, a value listed on the left is sent as the one on the right, so a finding status label can land as your instance's `state` choice. **Add translation** adds a pair, and a value not listed is sent unchanged. Editing the row's field or value keeps its translations. Clicking the arrows button on a row that has translations removes them.
**Reformatting a date.** The calendar button at the end of a row opens a date format for that value. Type a Python strftime pattern, such as `%m-%d-%Y`, and a value that resolves to a date is sent in that shape: `2027-01-31` becomes `01-31-2027`. An empty date stays empty. The pattern must name at least one date part, such as `%Y` or `%d`. The locale formats `%c`, `%x` and `%X`, and a few rarer codes such as `%f` and `%Z`, are not accepted. If the value is not a date when the step runs, the step is skipped with a message that names the value. Click the calendar button again to remove the format.
**Apply table template** fills in suggested rows when Coverbase has a template for the table and action. If the rows already hold something, it asks **Replace field mappings?** first.
| Action | Table | Rows the template fills |
| - | - | - |
| **Create** | External Assessment (VRA) | `vendor` and `engagement`, from the vendor's and service's `sys_id` |
| **Create** | Third Party (Vendor) | `name` and `website`, from the vendor |
| **Create** | Engagement | `name` from the service, and `vendor` from the vendor's `sys_id` |
| **Create one per issue or finding**, for issues | Third-party Risk Issue | `short_description`, `description`, and the `vendor` and `assessment` `sys_id` |
| **Create one per issue or finding**, for findings | Third-party Risk Issue | `short_description`, `description`, `explanation`, `due_date`, `vendor`, `assessment`, `assigned_to`, `state` and `applies_to` |
<Warning>
**Values are sent as written.** A choice column stores your instance's choice value, and a reference column stores a `sys_id`, so a label or an email address in either lands as text that your forms may not recognize. Check template rows against your instance before you switch the workflow on: the findings template sends the finding's status label to `state` and the assignee's email address to `assigned_to`. When a value needs translating, add translations to its row with the arrows button (see **Translating a value** above).
</Warning>
A variable with nothing behind it skips the whole step rather than sending a blank, exactly as described in [Placeholders in action text](/user-guides/building-a-workflow#placeholders-in-action-text).
## Creating a record
**Create** makes one record and remembers which Coverbase record it belongs to.
<Frame>
<img alt="The Coverbase automation inspector with the Create ServiceNow record action, the sn_vdr_risk_asmt_assessment table, Link ServiceNow record to set to Assessment, Match Existing Records On and two field mappings" />
</Frame>
| Field | What it does |
| - | - |
| **ServiceNow table** | The table the record is created in. |
| **Link ServiceNow record to** | The Coverbase record, taken from the triggering event, that the new record belongs to: **Assessment**, **Vendor**, **Service**, **Finding**, **Contract**, **Procurement**, **Engagement** or **Work queue item**. If the trigger cannot supply one, the step is **Skipped**. |
| **Match Existing Records On** | Optional. Before creating, look for a record whose chosen columns already hold exactly the values this step would send, and link that one instead. It lists the columns you have mapped. Leave it on **Always create a new record** unless many Coverbase records legitimately share one ServiceNow record, such as a location or a business application. |
| **Field mappings** | The record's contents. See [Mapping fields](#mapping-fields). |
A Coverbase record gets at most one linked record per table from **Create**. A second run for the same Coverbase record is **Skipped** with "A ServiceNow record in `<table>` is already linked to this `<record type>`". Push later changes with **Update**.
When **Match Existing Records On** is set, the step searches first:
| What the search finds | What the step does |
| - | - |
| No matching record | Creates the record and links it, as usual. |
| Exactly one | Links that record and leaves its contents unchanged. |
| More than one | **Failed**, listing the matching records. Remove the duplicates in ServiceNow or match on more columns. |
| A chosen column resolved to nothing | **Skipped**, since an empty value cannot identify a record. |
| A value containing `^` | **Failed**. ServiceNow reads `^` as a query separator. |
Matching is exact, so a value of `Acme Inc` does not match a record holding `Acme Inc.`, and the step creates a second record rather than linking one that may not be the same.
<Tip>
A **Create** step on an **Updated** trigger runs on every edit and is **Skipped** every time after the first. Put it on a **Created** trigger, or narrow the **Updated** trigger to the fields that matter, so the runs page stays readable.
</Tip>
## Updating the linked record
**Update** changes the record that a **Create** step, or a match, linked to the same Coverbase record. Set **ServiceNow table** and **Update record linked to** to the same table and record type as that step, and map only the columns you want to change: the step sends those and leaves the rest of the record alone.
If nothing is linked yet, the step is **Skipped** with "No ServiceNow record in `<table>` is linked to this `<record type>`". To update a record Coverbase did not create, link it first with a **Create** step that uses **Match Existing Records On**, which links an existing record without changing it, or address it by `sys_id` with **Send custom request**.
A typical pair: **Create** on **Assessment Created** opens the VRA record, and **Update** on **Assessment Updated**, watching the status field, sets the record's `state` as the assessment moves.
## One record per issue or finding
**Create one per issue or finding** turns an assessment's problems into records, such as one Third-party Risk Issue each, in a single step.
<Frame>
<img alt="The Coverbase automation inspector with the per issue or finding action, the sn_vdr_risk_asmt_issue table, Create one record for each set to Finding attached to the assessment, and the Idempotency column set to correlation_id" />
</Frame>
| Field | What it does |
| - | - |
| **ServiceNow table** | The table each record is created in. |
| **Create one record for each** | **Issue on the assessment**: one record per unresolved issue. **Finding attached to the assessment**: one record per finding raised in the assessment or linked to it later. |
| **Idempotency column** | A column that receives each record's Coverbase ID, `correlation_id` by default (tables that extend `task` have it). If a run is interrupted after ServiceNow created a record but before Coverbase recorded it, the next run finds that record by this column instead of creating a second one. It overrides a mapping row for the same column. Leave it empty only if the table has no suitable column. |
| **Field mappings** | What each record holds. The **Insert variable** menu adds the item's own fields. See below. |
For findings, five more settings choose which ones become records:
| Setting | Default | What it does |
| - | - | - |
| **Finding statuses** | **Open findings** | With nothing chosen, findings whose status is not completed or canceled. Choosing statuses replaces that rule. |
| **Finding severities** | **All severities** | Limits the records to the chosen severity levels. |
| **Finding sources** | **All sources** | Limits the records to findings from the chosen sources, such as **Raised in an assessment**, **Document review** or **Monitoring alert**. |
| **Include completed findings** | Off | Also sends completed and canceled findings. Turning it on reveals **Exclude canceled findings**, which keeps canceled ones (a risk acceptance, for example) out. Both are unavailable once you choose statuses. |
| **Only findings linked to an issue** | Off | Skips ad hoc findings, which have no control reference or control effectiveness to map. |
<Frame>
<img alt="The Coverbase per finding action showing the finding status, severity and source filters, the three switches and nine field mappings using item variables" />
</Frame>
### Item variables
Inside this action, `{{item:...}}` variables resolve to the issue or finding the record is for. **Insert variable** lists them under **Finding fields**, or under **Issue fields** and **Control fields**, next to the usual workflow variables. Custom fields on findings, issues and controls get groups of their own.
| For a finding | For an issue |
| - | - |
| `{{item:title}}`, `{{item:body}}`, `{{item:recommended_remediation}}` | `{{item:title}}`, `{{item:justification}}` |
| `{{item:status}}`, `{{item:severity}}`, `{{item:risk_level}}`, `{{item:due_date}}` | `{{item:score}}`, `{{item:score_percent}}`, `{{item:issue_category}}` |
| `{{item:assigned_to_email}}`, `{{item:vendor_external_id}}`, `{{item:url}}` | `{{item:control.expectation}}`, `{{item:control.external_idx}}` |
| `{{item:control_reference}}`, `{{item:control_effectiveness}}` | `{{item:public_idx}}`, `{{item:question}}`, `{{item:response}}` |
A finding has no control of its own, so its control variables come from its linked issue with the lowest index, and are blank for an ad hoc finding. Dates arrive as `YYYY-MM-DD`. An item variable with no value on one item sends a blank rather than skipping the step.
### How the step behaves over time
* **Each item gets one record per table.** The first run creates a record for every selected item. A later run creates records only for items that have none, so a finding added to the assessment afterwards goes out on the next run. With nothing new, the step is **Skipped** with "No unsynced findings on the assessment" (or issues).
* **A failure partway through keeps what landed.** If ServiceNow rejects a record, the step is **Failed** with the error and "after creating N of M records". The records already created stay linked, and the next triggering event resumes with the item that failed.
* **Service Now Sync Completed follows.** Once every selected item has its record, Coverbase raises **Service Now Sync Completed** for the assessment. Hang the closing step on it, for example an **Update** of the VRA record linked to the assessment. It can fire again when the step runs again with nothing new to send, so make the closing step safe to repeat.
* **Finding records stay reachable.** Each finding's record is linked to that finding, so an **Update** step with **Update record linked to** set to **Finding**, on a **Finding Updated** trigger, keeps the ServiceNow record current as the finding changes. Records made for issues cannot be targeted by **Update**.
## Sending a custom request
**Send custom request** sends one request, exactly as you write it, to any API path on your instance: a Table API record Coverbase did not create, or a scoped endpoint your ServiceNow team built.
<Frame>
<img alt="The Coverbase automation inspector with the Send custom ServiceNow request action, HTTP method PATCH, an endpoint path ending in the assessment external ID variable, and a JSON payload of workflow variables" />
</Frame>
| Field | What it does |
| - | - |
| **HTTP method** | `POST`, `PATCH` or `PUT`. |
| **Endpoint path** | The path after your instance's base URL, starting with `/api/`, for example `/api/now/table/sn_vdr_risk_asmt_assessment/{{assessment:external_id}}`. Variables work anywhere in it. It cannot contain `?`, `#`, `%` or empty and relative segments; put query strings in **Query Parameters**. The connection supplies the authentication. |
| **JSON payload** | A JSON object, sent exactly as written. Variables resolve inside string values. **Insert variable** above the editor adds one at the cursor. |
| **Query Parameters** | Optional **Name** and **Value** pairs added to the URL. `sysparm_input_display_value` set to `true`, for example, lets the Table API accept display labels instead of choice codes. |
| **Date Formats** | Optional. Each row names a **Payload field** and a strftime **Format**, such as `%m-%d-%Y`, applied after the variables resolve, so `2027-01-31` is sent as `01-31-2027`. An empty date stays empty. Formats apply before **Value Translations**. |
| **Value Translations** | Optional. Each row names a **Payload field** and rewrites a **Coverbase value** in it to a **ServiceNow value** after the variables resolve, so `Approved` can be sent as `3`. A value with no row is sent unchanged. |
Three payload forms go beyond plain text:
* **Leave a key out when its value is empty.** Add `|omitempty` inside the braces, as in `"u_rto": "{{questionnaire:answer:question_perma_id|omitempty}}"`. When the answer is blank, the key is dropped instead of the whole step being skipped. It works only when the placeholder is the key's entire value, and not in the path or query parameters.
* **Send a list or a number.** For a questionnaire trigger, **Selected answers to a question (list)** and **Selected answers to a question (objects)** arrive as a JSON array, and **Numeric value of an answer** as an unquoted number, when the placeholder is the key's entire value.
* **Translate or reformat a value.** **Value Translations** and **Date Formats** reach only top-level fields that are plain text in the payload. If a row names any other field, the form shows an error and the automation will not save.
The request links nothing in Coverbase and raises no events, so a later **Update** step cannot find what it wrote. The run step shows the path it called, the payload and ServiceNow's response.
## Uploading documents
**Upload documents** copies files from Coverbase into ServiceNow Document Management. Each document becomes a document record (`ds_document`) with a published version (`ds_document_version`) that holds the file.
<Frame>
<img alt="The Coverbase automation inspector with the Upload documents to ServiceNow action, Documents to upload set to assessment supporting documents, All document types, and the document record field mappings, with the type row's value translations open and each SOC report type sent as soc" />
</Frame>
| Field | What it does |
| - | - |
| **Documents to upload** | **Assessment supporting documents**, **The document from the trigger event** (for a vendor document trigger), or **Documents attached to the questionnaire submission**. If the trigger cannot supply them, the step is **Skipped**. |
| **Document types** | Limits the upload to the chosen types. Leave it on **All document types** to send everything in the source. |
| **Document record fields** | Columns on the document record. The defaults link it to the third party (`sn_vdr_risk_vendor` from `{{vendor:external_id}}`), set its `type` from the Coverbase document type, and describe it as the document type for the vendor. The name defaults to the file name and sharing is on; a row for either column overrides it. |
| **Document version fields** | Columns on the version, such as your instance's received and valid-to date columns, from `{{item:uploaded_at}}` and `{{item:expiration_date}}`. |
The **Insert variable** menu adds a **Document** group for these fields: **Name**, **File name**, **Document type**, **Document type label**, **Uploaded on**, **Valid to**, **Uploaded by**, **Uploaded by email**, **Size in bytes** and **Coverbase URL**.
The action manages a few columns itself and refuses a mapping for them: `state`, `default_version` and `external_file_url` on the document record, and `document` on the version. `external_file_url` holds the document's Coverbase link, which the action uses to find its own work again.
<Note>
**The default type row translates document types.** It sends Coverbase document types as the choice values a third-party risk instance usually uses (a SOC 2 report becomes `soc`, a master services agreement `msa`). Its translations are listed under the row, so change them there to match your instance. The row's arrows button removes them.
</Note>
Uploads run in the background. The step itself reads "Queued N document upload(s) to ServiceNow", and each file is linked when its upload finishes, which raises **Service Now Record Created**. A document that is already in ServiceNow is not sent again, and a step with nothing new to send is **Skipped** with "Every document is already in ServiceNow". An interrupted upload picks up the document it already created instead of making a second one. Files of 1 GB or more are not uploaded.
## Reading what a step sent
Open the run from the workflow's **History** tab or from **Workflow Runs** (see [Reading the runs page](/user-guides/building-a-workflow#reading-the-runs-page)). On a **Create**, **Update** or per-item step, the **Output** line links each record the step wrote to that record in your instance. Click the step's name to expand it: under the step and component IDs, each call is listed with its method and URL, the **Request payload**, the **Response body**, and the error when there was one.
For **Upload documents**, the uploads finish after the step, and each attempt is added to the step when it does: the file name, size and type, and the new record's `sys_id` or the reason it failed. Reload the run to see them.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| No **ServiceNow record** group in the action picker | The ServiceNow connection is not saved. | Save it on the **ServiceNow GRC** card under **Configuration** → **External Integrations**, or ask whoever manages integrations. |
| No **Create one per issue or finding** in the group | The trigger cannot reach an assessment. | Use an assessment trigger, or one whose record leads to an assessment. |
| **Skipped**: "ServiceNow integration is not configured" | The step ran with no saved connection. | Save the connection, then cause the trigger again. |
| **Skipped**: "A ServiceNow record in ... is already linked to this ..." | **Create** already ran for this Coverbase record and table. | Use **Update** for later changes. Move the **Create** step to a **Created** trigger if it keeps skipping. |
| **Skipped**: "No ServiceNow record in ... is linked to this ..." | **Update** found no record linked to this Coverbase record in that table. | Check that the table and **Update record linked to** match the **Create** step, and that the create has run. |
| **Skipped** with a message about an empty external ID | The vendor, service or assessment has no ServiceNow `sys_id` in Coverbase. | Load the IDs through the ServiceNow push or the [Import API](/import-api), or map the column from a custom field that holds them. |
| **Skipped**: "Could not resolve a ... from the triggering event" | The trigger does not lead to the record the step links to or reads. | Pick a record type the trigger supplies, or change the trigger. |
| **Failed** with a ServiceNow error such as a 403 | The connection's account lacks write access to that table. | Ask your ServiceNow administrator to grant it, then cause the trigger again. |
| **Failed**: "... records in ... already match" | **Match Existing Records On** found more than one record. | Remove the duplicates in ServiceNow, or match on more columns. |
| **Failed** partway, "after creating N of M records" | ServiceNow rejected one record in the batch. | Fix the cause in the error, then cause the trigger again. The step resumes with the item that failed. |
| A choice or reference field is blank or shows raw text in ServiceNow | The mapped value is a label or an email, not a choice value or `sys_id`. | Map a value your instance stores, add translations to the row (see **Translating a value**), or use **Send custom request** with **Value Translations** or `sysparm_input_display_value`. |
| "Enter an instance-relative path beginning with /api/" | The **Endpoint path** is a full URL or does not start with `/api/`. | Enter only the path; the connection supplies the instance. |
| A translation row shows an error and the automation will not save | The **Payload field** is missing from the payload, or is not plain text there. | Name a top-level text field from the **JSON payload**. |
| A date format shows "Use a strftime pattern with at least one date part" | The pattern names no date part, or uses a code Coverbase does not accept, such as `%c`, `%x` or `%X`. | Use a pattern such as `%m-%d-%Y` or `%Y/%m/%d`. |
| **Skipped**: "... is not an ISO date, so the date format ... cannot apply" | The mapped value is not a date, so the format cannot apply. | Remove the format from that row, or map a date variable. |
| The document `type` in ServiceNow is a raw Coverbase type | The default `type` row's translations were removed, or the row was deleted. | Delete the document record rows and click **Apply default mappings**. |
| The step after **Service Now Sync Completed** runs several times for one assessment | The per-item step ran again with nothing new to send, and each run ends with the event. | Narrow the per-item step's trigger, for example to the assessment's status changing, and make the closing step safe to repeat. |
| **Test connection** cannot be clicked | The connection has not been saved, or the form has unsaved changes. | Click **Save ServiceNow Configuration**, then test. |
## Related
<CardGroup>
<Card title="Building a workflow" icon="diagram-project" href="/user-guides/building-a-workflow">
Triggers, conditions, placeholders, testing, and reading runs.
</Card>
<Card title="ServiceNow integration guide" icon="server" href="/integrations/guides/servicenow">
What flows between Coverbase and ServiceNow VRM, and how the connection is provisioned.
</Card>
<Card title="Workflow templates" icon="wand-magic-sparkles" href="/user-guides/workflow-templates">
Ready-made automations you can extend with a ServiceNow step.
</Card>
<Card title="Webhooks" icon="tower-broadcast" href="/user-guides/webhooks">
Send Coverbase events, including the ServiceNow record events, to your own endpoints.
</Card>
</CardGroup>
# Bulk send
Source: https://docs.coverbase.com/user-guides/signature-bulk-send
Send one published signature template to a list of parties in one go. Every row becomes its own envelope, with its own routing and audit trail. The list format, prefilled fields, what each party receives, and tracking a batch.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. A bulk send starts from a published template, so read [Signature templates](/user-guides/signature-templates) first. Each row becomes an ordinary envelope, tracked as described in [Sending for signature](/user-guides/signature-envelopes). To write the agreement itself in Coverbase, see [the passage library](/user-guides/signature-passage-library).
</Info>
<Note>
Bulk send is part of e-signature. If you do not see **Signatures** and **Templates** under **Contracts** in the left navigation, ask your Coverbase account team to turn it on.
</Note>
Bulk send takes one published template and a list of parties, and makes one envelope per row. Use it when the paper is the same and only the counterparty changes: a mutual NDA for every new supplier, or revised terms for a whole category of vendors.
Each envelope it makes is an ordinary envelope. It has its own signing order, its own expiry, its own audit trail and its own executed copy, as if you had sent it through the wizard. The batch is the record of how they were made, and the place to see which rows went out.
The mistake people make most often is pasting a spreadsheet with its own column headings instead of the header line the page gives them: a heading that matches no party and no labeled field is ignored, and the batch sends without the values in that column.
## Before you start
* **Publish the template.** Only published templates are offered. See [Signature templates](/user-guides/signature-templates#publish-it).
* **Have a name and an email for every party on every row.** A template's parties are all required, and a bulk send cannot drop one. If your own signatory is the same person on every envelope, repeat them on every row.
* **Label the fields you want to prefill.** Only a field with a **Label** in the field inspector, and not set to **Read only**, can take a value from the list.
* **Build the template from Upload or Write.** A template built **From a document** or **From a contract** sits on one vendor's document, and Coverbase files the executed copy of every envelope sent from it among that vendor's documents.
* **Check the expiry and your signing settings.** Every envelope in a batch expires after the template's **Default expiration** when it has one, and otherwise after your organization's **Default Expiry (Days)**. Every envelope follows your organization's **Require email verification** setting. Both organization settings are under **Configuration → E-signature**. The bulk send page has no setting for either.
## Where it lives
| | |
| - | - |
| **Contracts → Signatures → Bulk sends** | Every batch your organization has sent, newest first, with **Bulk send** to start another. |
| **Contracts → Templates → Bulk send** | Goes straight to a new bulk send. |
## Send a batch
<Steps>
<Step title="Pick the template">
**Template** lists your published templates by name. Publishing a new version of a template retires the version it replaced, so each template is listed once. Once you pick one, **Columns the list needs** shows the header line for that template, with a copy button beside it.
</Step>
<Step title="Name the batch">
**Batch name** is how the batch appears under **Bulk sends**. Leave it empty and it takes the template's name. Signers never see it: each envelope has its own name.
</Step>
<Step title="Paste the list into Parties">
The first line must be the header. Either paste the header line from the page and add one comma-separated line per envelope under it, or put the same headings in the first row of a spreadsheet, one per column, and paste the cells in.
</Step>
<Step title="Read the preview">
The count above the preview is how many envelopes will be made. Each line shows the envelope's name and who fills each party. Anything that cannot be sent is listed in red, and **Send** stays grayed out until it is fixed.
</Step>
<Step title="Add a message">
**Email subject** becomes the subject line of every invitation in the batch. Leave it blank to use your organization's invitation wording. **Email message** is added to every invitation.
</Step>
<Step title="Choose how the links go out, and send">
Leave **Email every party their signing link** on unless you will hand the links out yourself. **Send** counts your rows (**Send 4 envelopes** for a list of four), queues the batch, and opens its page.
</Step>
</Steps>
<Frame>
<img alt="Bulk send page with the Mutual NDA template picked, a Columns the list needs panel showing the header line and a copy button, an empty Parties box, email fields, the email switch and a grayed-out Send button" />
</Frame>
<Frame>
<img alt="Bulk send page with a pasted comma-separated list, a preview table of envelopes with each party's name and email, the email subject and message filled in, and a Send 4 envelopes button" />
</Frame>
## How the list is read
The first line is the header. Every line after it that is not blank becomes one envelope.
| Column | Header | Needed |
| - | - | - |
| Envelope name | `envelope` (`envelope name`, `agreement` and `name` also work) | No. An empty cell names the envelope after the template and the first party, for example `Mutual NDA · Tomasz Nowak`. |
| A party's name | `<party> name` | Yes, for every party on every row |
| A party's email | `<party> email` | Yes, for every party on every row |
| A party's access code | `<party> access code` | No. See [access codes](#access-codes). |
| A field's value | The field's **Label** | No. See [prefilling fields](#prefilling-fields). |
`<party>` is either the key the header line uses (`party_1`) or the party's name as the template shows it (`Supplier signatory`). Headings ignore capitals, an underscore counts as a space, and the columns can come in any order, so `Supplier signatory email` and `party_1 email` are the same column.
What catches people out:
* A column headed `Name` on its own is read as the envelope name, not as anyone's name.
* `email` and `e-mail` both work.
* In comma-separated lines, wrap a value that contains a comma in double quotes: `"4 Wharf Road, Leeds"`. Cells pasted from a spreadsheet arrive separated by tabs and need no quotes.
* Two parties on one row cannot share an email address.
* A batch holds up to 500 rows.
* The preview shows the first 50 rows, and the red box the first 10 problems. Every row is sent.
* Problem messages count the header as row 1, so the first envelope is row 2. Blank lines are not counted. The title of the red box counts rows, so a row with two problems counts once.
<Frame>
<img alt="Bulk send page with a pasted list, a preview of three rows, a Columns ignored note, and a red box reading 2 rows cannot be sent with one problem for row 3 and one for row 4" />
</Frame>
### Prefilling fields
A column headed with a field's **Label** fills that field on the row's envelope. The header line on the page lists every field you can prefill, after the party columns.
* Only a field with a **Label** that is not **Read only** can be prefilled.
* The value goes into every field on the envelope with that label, whichever party the field belongs to. Give two parties' fields different labels if they need different values.
* The signer sees the value already filled in and can change it.
* Coverbase does not check the value against the field's options or format, so a **Dropdown** value has to match one of its options exactly.
* To prefill a field that has no label, add one in the template. If the template has been sent from, that means [a new version](/user-guides/signature-templates#versioning-what-freezes-and-when).
### Access codes
Add a `<party> access code` column to give that party an access code on their envelope, the same as setting **Identity Check** to **Access code** in the wizard. A code has to be 4 to 64 characters. The header line on the page does not include this column, so add it yourself.
Coverbase never shows a code again, on the batch page or anywhere else. Send each one to its party some other way, never in the signing email.
## What each party receives
With **Email every party their signing link** on, which is the default:
* Coverbase works down the list one row at a time, making and sending each envelope.
* Each envelope asks its parties in the template's order. The first is emailed an invitation when the envelope is sent, and the next when the step before them is done, as for any envelope ([routing order](/user-guides/signature-envelopes#step-2-the-recipients)).
* The invitation names you as the sender, names the envelope, and carries your **Email message**. Its subject line is your **Email subject**. Left blank, it is your organization's **Invitation** wording under **Signing Emails** in your signing settings, and without that it reads like *Jordan Lee sent you Mutual NDA · Kestrel Freight*.
* Expiry follows the template, and email verification your organization's settings, as described in [before you start](#before-you-start).
* When the last party signs, every party is emailed the executed copy.
With the switch off, it reads **Mint links only; I will distribute them**. Coverbase makes and sends every envelope but emails nobody. The batch page then has a **Signing Links** column: each sent row lists its parties, with a button that copies that party's own signing link, for you to send them. The envelope's **Portal link** works too: the party enters the email address the envelope was sent to, and Coverbase emails them a one-time code before the document opens.
## Track a batch
The batch page opens as soon as you send, and refreshes itself until the batch finishes. Across the top: the batch name and status, the template, who started it and when, and four counts: **Rows**, **Sent**, **Failed** and **Skipped**. Below it is one line per row. Once a row's envelope exists, its name links to it and **Sent** shows when it went out. A row that could not be sent shows the reason under its status.
<Frame>
<img alt="Batch page for Q4 supplier NDAs with a Queued badge, counts of 4 rows and 0 sent, failed and skipped, a Cancel remaining button, and four pending rows with envelope names and parties" />
</Frame>
| Batch status | Meaning |
| - | - |
| **Queued** | Accepted and waiting. Your organization's batches go out one at a time, so a batch waits while another is sending. |
| **Sending** | Rows are being turned into envelopes, in list order. |
| **Completed** | Every row was sent. |
| **Completed with failures** | Some rows were sent and at least one failed. The reason is on each failed row. |
| **Canceled** | Someone clicked **Cancel remaining**. |
| **Failed** | Every row failed, so nothing was sent. |
| Row status | Meaning |
| - | - |
| **Pending** | Not reached yet. |
| **Sent** | The envelope exists and has been sent. |
| **Failed** | This row could not be sent, for the reason shown. The rows after it carry on. |
| **Skipped** | The batch was canceled before this row was reached. |
On **Bulk sends**, **Progress** sums a batch up, for example *3 of 4 sent, 1 not sent*. "Not sent" counts failed and skipped rows together.
Each envelope from a batch is also listed on **Contracts → Signatures** like any other, and the first event on its audit trail says a bulk send created it. To remind, correct or void one, open it and use the actions in [Sending for signature](/user-guides/signature-envelopes#nudging-correcting-cancelling).
Three things to know about the envelopes a batch makes:
* **They are not filed against a vendor or a contract.** An envelope's **Details** read **Not associated with a vendor**. Use **Select a vendor** there if you want it on a vendor's record.
* **The executed copy is kept on the envelope**, where **Download signed copy** fetches it once every party has signed. It also lands among a vendor's documents only when the template was built on that vendor's document (see [before you start](#before-you-start)).
* **The first one sent freezes the template.** The template version is then cited in an audit trail, and changing it takes **Edit as new version**, as after any send.
### Cancel remaining
**Cancel remaining** shows while a batch is **Queued** or **Sending**. It stops every row that has not gone out: those rows become **Skipped** with the reason *Canceled by the sender*, and the batch reads **Canceled**.
Envelopes already sent stay out. To stop one of those, void it from the envelope.
<Frame>
<img alt="Batch page with a Canceled badge, counts of 4 rows and 4 skipped, and four rows marked Skipped with the reason Canceled by the sender" />
</Frame>
## Who can do what
| To | You need | Default roles that have it |
| - | - | - |
| See **Bulk sends** and open a batch | Read access to contracts | Admin, Member, Siloed Member, Guest |
| Start a bulk send | The organization-wide **create** permission on contracts | Admin, Member |
| **Cancel remaining** | The organization-wide **update** permission on contracts | Admin, Member |
Custom roles are covered in [Permissions and roles](/user-guides/permissions-and-roles).
## Limits
* Up to 500 rows in a batch. Split a longer list into several batches.
* One batch at a time per organization. Later batches wait as **Queued**.
* If your plan caps envelopes per month, the page says how many your plan still allows under **Columns the list needs**. A longer list shows **More envelopes than the plan allows** and cannot be sent.
* A batch cannot set its own expiry or email verification, add a private note for one party, or file its envelopes against a vendor or a contract.
## Troubleshooting
| Symptom | Cause | Fix |
| - | - | - |
| The template is not in **Template** | It is still a draft, or it was archived. | Publish it from the template builder. |
| **Template** lists a template twice, each with a version number such as **Mutual NDA · v2** | Two versions were published before publishing a new version retired the old one. | Pick the higher version. Publishing any newer version of the template retires the others. |
| Every row says **nobody is named for** a party | The headings do not name the template's parties, for example plain `Name` and `Email`. | Start again from the header line on the page. |
| **Columns ignored** names a column you need | Its heading matches no party column and no labeled, editable field. | Rename it to the field's **Label**, or to `<party> email`. To prefill a field with no label, label it in the template. |
| **Send** stays grayed out | No template is picked, the list has no rows under the header, the red box lists a problem, or the list is longer than your plan allows. | Fix what the page points to. |
| **The batch could not be queued.** | More than 500 rows, two parties on one row share an email, a name or envelope name is over 200 characters, or an access code is shorter than 4 or longer than 64 characters. | Fix the list, or split it into smaller batches. |
| A batch stays **Queued** | Another batch from your organization is still sending. | Wait for it to finish. If nothing else is sending, contact support. |
| A row **Failed** with *The plan's monthly allowance of N envelopes is used up.* | Your plan's envelope allowance ran out part way through the batch. | Send the failed rows again as a new batch once your allowance allows it. |
| A party never received an invitation | The email switch was off, the party is in a later step, or the address is wrong. | With the switch off, copy their link from **Signing Links** on the batch page. Otherwise hand them the envelope's **Portal link**. For a wrong address, use **Correct and resend** on the envelope. |
| Every executed copy was filed on one vendor | The template was built **From a document** or **From a contract**, so it sits on that vendor's document. | Build templates for bulk sends from **Upload** or **Write**. |
## Related
<CardGroup>
<Card title="Signature templates" icon="file-lines" href="/user-guides/signature-templates">
Build and publish the template a bulk send starts from, and label the fields you prefill.
</Card>
<Card title="Sending for signature" icon="paper-plane" href="/user-guides/signature-envelopes">
Track, remind, correct or void each envelope the batch made.
</Card>
<Card title="The signing experience" icon="pen-nib" href="/user-guides/signature-signing-experience">
What every party on the list sees when they open their link.
</Card>
<Card title="E-signature overview" icon="signature" href="/user-guides/signature-overview">
Envelope statuses, and the signing settings every envelope in a batch follows.
</Card>
</CardGroup>
# Sending for signature
Source: https://docs.coverbase.com/user-guides/signature-envelopes
Create an envelope from a template or a document, name who signs and in what order, send it, and track it to a sealed executed copy with a hash-chained audit trail.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. Read the [e-signature overview](/user-guides/signature-overview) for how the pieces fit together, and [templates](/user-guides/signature-templates) for building the paper you send from.
</Info>
An envelope is one agreement, out for signature, addressed to named people. It is the object that binds the parties, and the one that carries the record of what happened.
## Start an envelope
**New Envelope** on **Contracts → Signatures** opens a four-step wizard. You can also start one with **Send for signature** in the **Signature** step of a contract's **Workflow** tab, which files the envelope against that contract. Nothing is saved until you send, so leaving the wizard part way leaves nothing behind.
### Step 1: the document
<Frame>
<img alt="Send wizard step one showing envelope name, the five paper sources with Upload selected, associated vendor and expiration" />
</Frame>
**Envelope Name** names the agreement in every email Coverbase sends about it, and is the name the executed copy is filed under. Make it something the counterparty will recognize.
Then pick the paper. **From a template** copies a template's roles and field layout across. **From a document**, **From a contract**, **Upload** and **Write** all start you with paper and no fields, which you place yourself in step 3. **Upload** takes several files, which travel as one envelope. **Write** lets you write the agreement in Coverbase, inserting passages from your library, and renders it to a PDF.
**Associated vendor** files the agreement against a counterparty. Set it even when it feels obvious: it puts the envelope on that vendor's record, and it pre-fills a **Company** field for the signer.
**Expiration** starts at 30 days, or at whatever the template or your organization's settings specify. Change the number, or switch to **Expires on** and pick a date.
<Note>
The unit selector next to the number changes how the deadline is written, not what it is. If the day count does not divide evenly into weeks or months the selector stays on days rather than showing a rounded figure that disagrees with what is sent.
</Note>
### Step 2: the recipients
<Frame>
<img alt="Send wizard recipients step showing name, email, private note, recipient type, signing step and identity check for a party" />
</Frame>
If you are signing something yourself and nobody else is involved, turn on **I am the only signer** at the top. It sends the envelope to you alone in a single step, and drops any other party you had added.
Otherwise, each party gets a card. Four kinds:
| Type | What they do |
| - | - |
| **Signer** | Signs. The envelope is not complete until every signer has. |
| **Approver** | Approves rather than signs. Blocks the envelope the same way a signer does, but applies no signature. |
| **Witness** | Signs as a witness to another party. Blocks like a signer. |
| **Copied** | Receives the agreement for information. Never blocks, and never has fields. |
Name and email autocomplete from you, your colleagues, and the people on the associated vendor (its relationship owners, risk analysts, watchers and contacts), so a party you have dealt with before is two keystrokes.
**Signs in step** is the routing order, and reads **Approves in step** on an approver. Parties in step 1 are asked immediately; step 2 is notified when step 1 finishes, and so on. Give two parties the same step and they are asked at the same time. Drag a card by its handle to reorder the list.
<Warning>
A copied party has no step number, because copies go out as soon as the envelope is sent, regardless of routing. Their card reads **Delivery: emailed a copy when the envelope is sent**. That email says who sent the agreement and carries the document as a PDF attachment, with no signing link. If it cannot be sent, Coverbase sends it again when the next signing step goes out. When every party has signed, they also get the executed copy. If you need someone to receive the agreement only after it is executed, a copied party is not that.
</Warning>
**Private Note** is a line only that one recipient sees. It is the place for "this is the revised schedule we discussed" without putting it in front of everybody else on the envelope.
**Identity Check** is per party, and defaults to **None**. Set it to **Access code** and Coverbase generates a code for that recipient, which they must enter before the document opens.
<Warning>
Send an access code to the signer by some other channel: a call, a text, anything that is not the signing email. Coverbase stores it as a digest and never shows it again once the envelope is sent, so copy it before you send. The refresh icon beside the field mints a new one if you lose it.
</Warning>
If a template supplied the roles, the seats are already there and you are only filling in names and addresses. Fields follow the role, so changing who sits in a seat keeps their placements.
### Step 3: the fields
Same canvas as the template builder: parties down the left, palette below them, document in the middle, inspector on the right. If you came from a template the fields are already placed and this step is a review; if you came from a bare document, this is where you place them.
<Frame>
<img alt="Send wizard fields step with the document canvas and field palette" />
</Frame>
Everything in [the field types](/user-guides/signature-templates#what-the-field-types-do) applies here unchanged.
### Step 4: review and send
<Frame>
<img alt="Send wizard review step showing signing order, signing emails, signature meaning and the notify and authenticate toggles" />
</Frame>
**Signing Order** at the top is the last look at who is asked, in what order, and how many fields each one owns. The step numbers are still editable here and the rows still drag, so a routing mistake spotted at the end does not send you back a step.
**Signing Emails** is the invitation. **Subject** is the invitation's subject line for this envelope. Leave it blank and the invitation uses your organization's own invitation subject from Signing Settings, or, without one, Coverbase's built-in *Jordan Lee sent you Mutual NDA*. **Opening line** is added to every party's invitation. **Rewrite** drafts both from the document itself, which is usually a better starting point than a blank box.
**What does signing mean?** is recorded with every signature on the envelope. Most agreements do not need it. Regulated workflows do, and some organizations require it on every envelope. The step says so if yours does.
Two switches decide how it goes out:
| | |
| - | - |
| **Email recipients the signature link** | On by default. Turn it off and links are minted but not sent, for when you are handing them out yourself. The send button then reads **Create and get links**, and the page that follows lists each party's link once, because only a digest is stored. |
| **Authenticate signers' identity** | Whether a party must verify their email address before the document opens. Starts at your organization's setting and can be changed for this envelope alone. |
**Send for signature** emails the first routing step, emails each copied party their copy, and gives the agreement one permanent portal address.
## Track what is out
The envelope's **Overview** tab is the working view. Down the middle: the source document with **Open the original**, **Download full packet** and **Verify now**, and under it **Fields and Values**, listing every field, whose it is, what it holds, which page it sits on and when it was filled. Down the right: the signing order, the envelope's details, and the portal link.
<Frame>
<img alt="Envelope detail overview showing document actions, fields and values, signing order, details and portal link" />
</Frame>
**Signing Order** is where you look when someone asks "where is this?" It reads per party (approved, opened but not signed, not yet asked) rather than as one envelope-level status. The badge beside the envelope name says which template version it came from.
**Details** carries the vendor the agreement is filed against, when it was sent, when it expires, when it completed, and how many documents it holds. The vendor can be changed from here if it was set wrong.
<Note>
The **portal link** is a permanent address for the agreement, for handing it over out of band or back to a party whose invitation link has expired. Holding the link is not enough to open it. The visitor enters their email address, and Coverbase emails a one-time code only to a party on the envelope whose turn it is, or to any party once the envelope is executed. Nothing is shown until that code is entered.
</Note>
### Nudging, correcting, cancelling
<AccordionGroup>
<Accordion title="Send Reminder">
Resends a reminder link to the parties currently pending. It does not touch anyone who has already signed and it does not disturb the routing order.
</Accordion>
<Accordion title="Correct and resend">
For when the document or the recipients were wrong. The original is voided with its trail intact and you rebuild it in the send flow with everything carried across, so you are not retyping the whole envelope. The voided original stays in the list for the record, and a banner across the rebuild says which envelope you are correcting.
Field *values* are not carried: a value belongs to the signature that was collected on the old envelope, not to the new one. Access codes are not carried either. A party who had one comes back with **Identity Check** set to **None**, so set a new code if you still want one.
</Accordion>
<Accordion title="Void envelope">
Closes every signing link immediately. Signatures already collected stay on the record. Voiding cancels the agreement; it does not erase what happened. A **reason** is required, and it goes into the audit trail beside the void.
</Accordion>
</AccordionGroup>
<Tip>
A signer can also decline, and a decline stops the envelope rather than skipping that person. Nobody further down the routing order is asked.
</Tip>
## What you get when it completes
Once the last party signs, Coverbase flattens every field into the page, seals the PDF, and generates a signing certificate beside it.
<Frame>
<img alt="Executed envelope detail with Download signed copy as the primary action, every field signed, and both parties green in the signing order" />
</Frame>
* **Download signed copy**: the sealed PDF, with every signature, initial and stamp burned into the page and attributed. It appears in the envelope's header, in place of **Send Reminder**, once every party has signed.
* **Download certificate**: the certificate of completion, under **Actions**. It only exists once every party has signed.
* **Download full packet**: the signed copy and the certificate together, for handing to a counterparty or an auditor.
* The document line under the file name reads **sealed at B-B** (or whatever level was achieved), so you can see what the executed copy carries rather than what was asked for.
Where the executed copy and the certificate are filed depends on where the paper came from:
* **Paper from a vendor's documents.** When the paper was picked **From a document** or **From a contract**, or came from a template built on one, both are added to the documents of the vendor that owns that document.
* **An envelope sent for a contract.** When the envelope was started from a contract's **Workflow** tab, or its paper was picked **From a contract**, the executed copy is also added to that contract's documents. Signed from one of the contract's own documents, it takes that document's role, and the unsigned version stays on the contract as a **Redline** of it. So signing the contract's **Root** document makes the signed copy the new **Root**. Paper the contract never held becomes its **Root** if it has none, and otherwise joins its documents as **Unmatched**, for you to set its role. Uploaded or written paper is filed on the contract's vendor.
* **Anything else.** Uploaded or written paper on an envelope that is not for a contract stays on the envelope, where **Download signed copy** and **Download certificate** fetch it. The **Associated vendor** does not file it.
## The audit trail
Every event is recorded in order and hash-chained: each entry carries a sequence number and a hash that covers the one before it. Removing or editing an entry breaks the chain, so tampering is detectable.
<Frame>
<img alt="Audit trail showing envelope created, sent, signer notified, portal opened, consent accepted, signature adopted and signed events with IP addresses and hashes" />
</Frame>
Events cover the whole life of the envelope: created, sent, each party notified, each portal opened, consent accepted against a specific disclosure version, each signature adopted and applied, and the final seal. Portal events carry IP, approximate location and user agent.
The **Integrity** panel beside it names the seal level applied (or **Not sealed** until every party has signed), when the seal was last verified, and the hashes:
| | |
| - | - |
| **Source Document SHA-256** | The hash of the paper before anyone touched it. |
| **Executed Document SHA-256** | The hash of the executed copy. Recorded once the envelope completes. At B-B the seal adds no bytes, so after sealing this row reads **Executed and Sealed SHA-256**; above B-B a separate **Sealed Bytes SHA-256** row sits beside it. |
| **Audit Chain Head** | The hash covering every event so far. |
<Tip>
**Verify now** on the Overview tab re-validates the stored executed copy against its seal the way a PDF reader would, and records the verdict under **Last verification** in the Integrity panel. That is the answer to "is this the file that was signed?"
</Tip>
## Common problems
<AccordionGroup>
<Accordion title="A signer says the link does nothing">
Check the envelope status first. A voided or expired envelope closes its links. If the envelope is live, check what the party has to get past before the document appears: **Authenticate signers' identity** emails them a one-time code, and an **Access code** on their recipient card asks for the code you were meant to hand them yourself. Either screen can be mistaken for a broken link.
</Accordion>
<Accordion title="Nobody after the first person has been emailed">
That is how routing works. Later steps are notified as the envelope advances. If the first step has not finished, nobody after it has been asked.
</Accordion>
<Accordion title="A copied party says they never got a copy">
Their copy goes out when the envelope is sent, as an email with the document attached. Nothing is emailed to anyone, copied parties included, when **Email recipients the signature link** was off. Check their address on the envelope, and look for **Party notified** against their name on the audit trail.
</Accordion>
<Accordion title="The envelope sat at Preparing this document">
Word files convert to PDF before they can be shown. The portal polls and resolves itself when the conversion lands, so a signer does not need to refresh.
</Accordion>
<Accordion title="The template will not let me edit it">
An envelope has been sent from it, so the version is cited in an audit chain. Use **Edit as new version**; see [versioning](/user-guides/signature-templates#versioning-what-freezes-and-when).
</Accordion>
</AccordionGroup>
## Related
<CardGroup>
<Card title="E-signature overview" icon="signature" href="/user-guides/signature-overview">
Envelope statuses, signing settings, and what Coverbase keeps.
</Card>
<Card title="Signature templates" icon="file-lines" href="/user-guides/signature-templates">
Build the paper you send from, with roles and fields placed once.
</Card>
<Card title="The signing experience" icon="pen-nib" href="/user-guides/signature-signing-experience">
What the parties on your envelope see, and what to tell one who is stuck.
</Card>
<Card title="Contract intake and approval" icon="clipboard-check" href="/user-guides/contract-intake-and-approval">
Sending an approved contract through DocuSign instead.
</Card>
<Card title="Bulk send" icon="users" href="/user-guides/signature-bulk-send">
Send one template to a list of parties, one envelope per row.
</Card>
</CardGroup>
# E-signature overview
Source: https://docs.coverbase.com/user-guides/signature-overview
How Coverbase gets an agreement signed: the template you build once, the envelope you send from it, what the counterparty sees, and the sealed copy and audit trail you keep afterwards.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It is the entry point for signing. The five guides that follow it go deeper: [templates](/user-guides/signature-templates), [the passage library](/user-guides/signature-passage-library), [envelopes](/user-guides/signature-envelopes), [bulk send](/user-guides/signature-bulk-send), and [the signing experience](/user-guides/signature-signing-experience).
</Info>
Coverbase signs agreements in the same place it stores them, so there is no exporting a PDF, sending it somewhere else, and filing the executed copy back by hand. The contract, the signature, the record of what happened, and the sealed document all sit on the same record.
<Note>
Coverbase also connects to [DocuSign](/integrations/guides/docusign) if your organization already signs there. The two are alternatives, not layers: DocuSign creates the envelope in your own DocuSign account, while everything on this page happens inside Coverbase. Pick one per agreement rather than both. On a contract record both start from the **Signature** step of the **Workflow** tab, once the contract has cleared its approval chain; see [Contract intake and approval](/user-guides/contract-intake-and-approval). A DocuSign envelope is still listed on **Contracts → Signatures**, with the status DocuSign reports.
</Note>
## The four things
<CardGroup>
<Card title="Template" icon="file-lines" href="/user-guides/signature-templates">
The paper you send repeatedly, with the signing parties and the fields already placed. Built once, used many times.
</Card>
<Card title="Envelope" icon="paper-plane" href="/user-guides/signature-envelopes">
One agreement, out for signature, addressed to named people. Created from a template or from a document on its own.
</Card>
<Card title="Portal" icon="pen-nib" href="/user-guides/signature-signing-experience">
What your counterparty opens. No account, no download, a link that works on a phone.
</Card>
<Card title="Executed copy" icon="shield-check" href="/user-guides/signature-envelopes#the-audit-trail">
The sealed PDF plus a hash-chained record of everything that happened to it.
</Card>
</CardGroup>
## The shape of a signing
A template is optional. The parts that are not optional are the envelope, the signing, and the copy you keep.
<Steps>
<Step title="Build a template, or skip it">
A template holds a source document, the **signing parties** as roles rather than people, and the fields each role fills. If this is a one-off, start from a document instead and place the fields on the envelope itself.
</Step>
<Step title="Create an envelope and name the people">
The template's roles become empty seats. You fill in who sits in each one, in what order they are asked, and how long they have.
</Step>
<Step title="Send it">
Coverbase emails the first routing step. Later steps are notified as the envelope advances, so nobody is asked before it is their turn.
</Step>
<Step title="They sign in the portal">
Consent, then adopt a signature, then fill what is theirs. Everything they do is timestamped and recorded against their address.
</Step>
<Step title="Coverbase seals the result">
Once the last party signs, the fields are flattened into the page, the document is sealed, and a signing certificate is generated alongside it.
</Step>
</Steps>
## Where everything lives
| | |
| - | - |
| **Contracts → Signatures** | Every envelope, with cards for what is in flight, stalled, expiring, executed and closed. |
| **Contracts → Signatures → Bulk sends** | Every [bulk send](/user-guides/signature-bulk-send): one template sent to a list of parties, one envelope per row. |
| **Contracts → Templates** | The templates your organization sends from. |
| **Contracts → Templates → Passage Library** | The [clauses and other passages](/user-guides/signature-passage-library) your team inserts when writing an agreement in Coverbase. |
| **Configuration → E-signature** | Opens **Signing Settings**: seal level, consent wording, accepted signature types, verification, email copy and portal branding. Set once, applies to everything. |
<Frame>
<img alt="Signatures inbox showing in flight, stalled, expiring this week, executed and closed cards above a table of agreements" />
</Frame>
## An envelope's statuses
Status is about the envelope as a whole. Each recipient also has their own state, which is what the **Waiting On** column reads.
| Status | Meaning |
| - | - |
| **Draft** | Created but not sent. Nobody has been emailed and nothing is binding. |
| **Out for signature** | Sent, with the first routing step asked. No signatures yet. |
| **Partially signed** | At least one party has signed and at least one has not. |
| **Executed** | Every party has signed. The sealed copy and certificate exist. |
| **Declined** | A party refused. The envelope stops; nobody further is asked. |
| **Voided** | You canceled it. Links stop working. |
| **Expired** | The expiry date passed before everyone signed. |
| **Failed** | Sealing did not complete. Rare; raise it with support. |
| **Delivered** | DocuSign envelopes only. Everyone in the current routing step has opened it and nobody has signed yet. |
Each recipient also carries their own state: *not yet notified*, *notified*, *opened*, *consented*, *signed*, *completed*, *declined* or *delegated*, plus *address bounced* on a DocuSign envelope. That is what the envelope's **Signing Order** panel reads out, party by party.
<Note>
The send wizard saves nothing until you click **Send for signature**, so opening it and abandoning it leaves no draft behind. Only a sent envelope freezes the template it came from.
</Note>
## Before your first send
Signing settings are organization-wide and only need doing once. They cover the seal, the consent wording, what signers may do, and how the emails and the portal look.
<Frame>
<img alt="Signing Settings page showing seal and certificate, electronic signature consent, and signing rules sections" />
</Frame>
<AccordionGroup>
<Accordion title="Seal and Certificate">
**Target Seal Level** is the PAdES level Coverbase aims for on the executed copy. Anything above B-B needs a signing certificate and a **Timestamp Authority URL**; until both are provisioned, envelopes are sealed and reported at the level achieved rather than the one you asked for. The page says which of the two is missing.
</Accordion>
<Accordion title="Electronic Signature Consent">
The ESIGN disclosure every signer sees before any field becomes writable. It is stored verbatim with each acceptance, so editing it publishes a new version and acceptances already recorded keep the text they were shown. A later edit cannot appear to change what someone agreed to.
</Accordion>
<Accordion title="Signing Rules">
**Accepted Signature Types** decides which ways of signing the signing page offers: **Drawn** and **Typed**. **Uploaded image** is also listed, but the signing page has no upload option today, so ticking it adds nothing for a signer. **Default Expiry (Days)** is what a new envelope starts at when nothing more specific applies. **Require a signature meaning** makes every signature record what the signer intended by it, which regulated workflows need and most do not.
</Accordion>
<Accordion title="Signer Verification">
Turn on **Require email verification** and a party must prove the address the agreement was sent to before the document is shown. The invitation links to the portal, which checks a one-time code first. Use it when the counterparty's address is the only thing identifying them. This is the default a new envelope starts at, and the sender can change it for one envelope on the review step. **Code lifetime (minutes)** sets how long a code stays valid; five wrong guesses spend a code whatever it says.
</Accordion>
<Accordion title="Signing Emails and Portal Branding">
Your own wording for the invitation, reminder, completion, declined and verification code mail; leave a field blank to keep the built-in copy. A **Subject** typed for one envelope, or an **Email subject** on a bulk send, replaces your invitation subject for that send. **Portal Branding** sets the **Sender Name** and a **Portal Message** shown on the signing page; the logo and accent come from your organization's branding. Both are covered in [the signing experience](/user-guides/signature-signing-experience#branding-the-portal).
</Accordion>
</AccordionGroup>
## What Coverbase keeps
Every envelope carries three tabs.
* **Overview**: the document, the parties, the fields and their values, and the portal link.
* **Audit trail**: every event, hash-chained, with IP and user agent. Covered in [envelopes](/user-guides/signature-envelopes#the-audit-trail).
* **Certificate**: the signing certificate generated when the envelope completed.
<Tip>
The audit trail is what answers "prove this person signed this document on this date". It records the source document's SHA-256 before anyone touched it and the executed document's SHA-256 after sealing, so a reader can check the file they are holding against the record.
</Tip>
## Related
<CardGroup>
<Card title="Signature templates" icon="file-lines" href="/user-guides/signature-templates">
Build the paper you send repeatedly: roles, fields, publishing and versioning.
</Card>
<Card title="Sending for signature" icon="paper-plane" href="/user-guides/signature-envelopes">
Create an envelope, name who signs, send it, and track it to an executed copy.
</Card>
<Card title="The signing experience" icon="pen-nib" href="/user-guides/signature-signing-experience">
What your counterparty sees in the portal, and how to brand it.
</Card>
<Card title="Contract intake and approval" icon="clipboard-check" href="/user-guides/contract-intake-and-approval">
The DocuSign path from a contract's Workflow tab.
</Card>
</CardGroup>
# The passage library
Source: https://docs.coverbase.com/user-guides/signature-passage-library
Keep the clauses, party blocks and signature pages your team reuses in one library, start from Coverbase's starter passages, and insert them when you write an agreement in Coverbase instead of uploading one.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the passage library and the **Write** option that uses it. To make what you write into a template you send again, see [Signature templates](/user-guides/signature-templates). To send it, see [Sending for signature](/user-guides/signature-envelopes), or [Bulk send](/user-guides/signature-bulk-send) for many parties at once.
</Info>
<Note>
The passage library is part of e-signature. If you do not see **Signatures** and **Templates** under **Contracts** in the left navigation, ask your Coverbase account team to turn it on.
</Note>
A passage is agreement text you use more than once: the paragraph that names the parties, a confidentiality clause, a signature page. The passage library holds your organization's passages. When you write an agreement in Coverbase instead of uploading one, **Insert passage** puts any of them into the document at your cursor, and Coverbase turns the finished text into the PDF that gets signed.
The library only feeds that editor. It does not review contracts or check clauses against a standard; that is [Contract Guardian](/user-guides/contract-guardian). A passage is also never a field. Signature and date fields are placed afterwards, on the rendered PDF.
The mistake people make most often is treating the square-bracket placeholders in a passage, such as `[Company name]`, as blanks Coverbase fills in: they are ordinary text, and they reach the signer exactly as written unless you replace them before you render.
## Where it lives
Open **Contracts → Templates** and click **Passage Library**. Your signature templates are the list on **Contracts → Templates** itself.
<Frame>
<img alt="Passage Library page listing passages with category badges and updated dates, an edit and an archive button on each row, and a Starter passages card with Add to library buttons" />
</Frame>
| | |
| - | - |
| **Passage** | The title, with the start of the text under it. |
| **Category** | **Clause**, **Heading**, **Parties**, **Signature page**, **Cover** or **Other**. A label for the list. It does not change how the text looks or where it goes. |
| **Updated** | When the passage was last saved. |
| Pencil and archive icons | **Edit passage** and **Archive passage**. |
**Search passages** matches any part of a passage's title or text. It filters your passages, not the **Starter passages** below them. **Show archived** adds archived passages to the list, marked **Archived**, each with **Restore**.
Passages belong to the organization. Everyone who can open the page sees the same library, and a change one person saves is what everyone inserts from then on.
## Start from the starter passages
Coverbase ships nine starter passages, written for an agreement between two parties. **Add to library** copies one into your library, where it is yours to edit. The copy is not linked to Coverbase's wording, so nothing in your library changes unless someone in your organization changes it.
| Starter | Category | What it says |
| - | - | - |
| **Parties (two parties)** | Parties | Names the two parties, "Company" and "Counterparty", and makes the date of the last signature the Effective Date. |
| **Confidentiality (mutual)** | Clause | Each party protects the other's confidential information, with the usual exclusions. Survives five years after termination. |
| **Term and termination** | Clause | A fixed term that renews automatically, notice of non-renewal, and termination for breach or insolvency. |
| **Fees and payment** | Clause | Counterparty pays Company's invoices within a set number of days, pays the taxes on them, and owes interest on late payment. |
| **Limitation of liability** | Clause | No indirect damages, and liability capped at what Counterparty paid or owed Company over a set period before the claim, with the usual exceptions. |
| **Governing law and venue** | Clause | The governing law and the courts that hear disputes. |
| **Notices** | Clause | How formal notices are delivered, including by email. |
| **Entire agreement, amendment and counterparts** | Clause | The agreement is the whole deal, changes must be signed by both parties, and electronic signatures count. |
| **Signature page (two parties)** | Signature page | Starts a new page with signature, name, title and date lines for each party. |
Two things to settle once, in your library copy, before anyone uses the starters:
* **The placeholders that are really your standard position.** Every starter marks what varies in square brackets: `[jurisdiction]`, `[twelve (12) months]`, `[thirty (30)] days`, `[the State of Delaware]`. Replace the ones your organization always answers the same way. Leave the deal-specific ones, such as names and addresses, for each document.
* **Which side you are on.** In **Fees and payment** and **Limitation of liability**, Counterparty pays Company. If your organization is the one paying, swap the two before you rely on them.
Picking a starter from **Insert passage** while you write also adds it to your library. Once added, a starter drops out of **Starter passages**.
<Frame>
<img alt="Edit passage dialog for Parties (two parties), category Parties, with text containing bracketed placeholders for company name, jurisdiction, entity type and address" />
</Frame>
## Add or change a passage
<Steps>
<Step title="Click New passage, or the pencil on a row">
**New passage** opens an empty dialog. The pencil opens the same dialog as **Edit passage**.
</Step>
<Step title="Give it a title and a category">
The title is the only thing the **Insert passage** menu shows, alphabetically and with no search. Name passages so the right one is easy to spot in a list: "Confidentiality (mutual, 3 years)" rather than "Clause 4".
</Step>
<Step title="Write the text">
Type `/` for a heading, a list or a quote, and select text to make it bold or italic. You can also paste Markdown. To start a new page, put `\pagebreak` on a line of its own.
</Step>
<Step title="Click Save passage">
It stays grayed out until the passage has both a title and some text. **Passage saved.** confirms it.
</Step>
</Steps>
<Frame>
<img alt="New passage dialog with the title Return of data on termination, category Clause, and a heading followed by a paragraph containing a bracketed placeholder" />
</Frame>
Saving changes the passage for every document written after it. Documents already written keep the text they had, because inserting a passage copies its text into the document rather than linking to it.
The library keeps no history of earlier wording. **Updated** is the only sign that a passage changed, so copy the old text somewhere first if you may need it again.
### What reaches the PDF
| Carries through | Prints as plain text |
| - | - |
| Headings, paragraphs, **bold** and *italic*, bulleted and numbered lists, block quotes, horizontal rules (`---` on its own line), and `\pagebreak` on its own line | Everything else. A table prints as its raw text, and a link prints its words without the web address. |
The PDF is US Letter size, and the document title is printed at the top of the first page.
## Archive a passage
The archive icon on a row asks you to confirm, then removes the passage from the library and from the **Insert passage** menu. The message that confirms it has **Undo**, which brings it straight back. Later, turn on **Show archived** and click **Restore** on its row. Documents that already used the passage are not affected either way.
Archiving an added starter puts it back under **Starter passages**. Adding it again gives you Coverbase's original wording, not the version you had edited. To get your edited wording back, restore your archived copy instead.
## Write an agreement with passages
**Write** is one of the paper sources in two places, and it works the same way in both:
* Step 1 of the send wizard (**New Envelope** on **Contracts → Signatures**), for a single agreement.
* The **New Template** dialog (**New template** on **Contracts → Templates**), for paper you will send again.
<Steps>
<Step title="Choose Write">
The editor opens below the paper sources.
</Step>
<Step title="Set the document title">
**Document title** is printed at the top of the first page and names the PDF. It starts as the envelope or template name. If that name is still empty when you render, the title fills it in.
</Step>
<Step title="Write, inserting passages as you go">
Click where a passage should go, then pick it from **Insert passage**. The menu lists **Your library** first, then the **Starter passages** you have not added. Choosing a starter also adds it to your library.
</Step>
<Step title="Replace every placeholder">
Use your browser's find (Ctrl+F, or Cmd+F on a Mac) to look for `[`. Anything still in square brackets reaches the signer as written.
</Step>
<Step title="Render it">
Click **Render and use this document** in the wizard, or **Render and use as the template** in the dialog. Coverbase turns the text into a PDF, and that PDF is the paper from then on. In the dialog, **Create template** then opens the template builder on it.
</Step>
<Step title="Place the fields">
Signature and date fields go on the rendered pages: in step 3 of the wizard, or in the template builder.
</Step>
</Steps>
<Frame>
<img alt="Send wizard step one with Write selected, a document title, two inserted passages in the editor, and the Insert passage menu open showing Your library and Starter passages" />
</Frame>
<Warning>
**Signature page (two parties)** draws signature, name, title and date lines as text, and nobody can sign a line of text. Place a **Signature** field over each signature line on the rendered page, and a **Date signed** field if you want the date filled in, or the signer has nothing to sign there. The field types are covered in [Signature templates](/user-guides/signature-templates#what-the-field-types-do).
</Warning>
You can change the text and render again before you move on, and the new PDF replaces the old one. Each render updates the same document, and the line beside the button counts them, as in **Version 2 · 3 pages rendered**. Once you leave the wizard or the dialog, what you wrote cannot be reopened for editing: the envelope or template keeps the rendered PDF. If you expect to send the same wording again, write it in the **New Template** dialog so it becomes a template, or keep its pieces as passages.
## Who can do what
| To | You need | Default roles that have it |
| - | - | - |
| Open the library and see its passages | Read access to contracts | Admin, Member, Siloed Member, Guest |
| Add a passage, add a starter, or render what you wrote | The organization-wide **create** permission on contracts | Admin, Member |
| Edit, archive or restore a passage | The organization-wide **update** permission on contracts | Admin, Member |
The buttons show for everyone who can open the page. Without the permission, saving fails with an error. Custom roles are covered in [Permissions and roles](/user-guides/permissions-and-roles).
## Limits
* A title can be up to 200 characters, and a passage's text up to 200,000.
* A written document can be up to 200,000 characters.
* The library page and the **Insert passage** menu show the first 100 passages by title. **Search passages** still finds one further down, but the menu cannot offer it.
* There is no version history for a passage, and no list of the documents that used one.
## Troubleshooting
| Symptom | Cause | Fix |
| - | - | - |
| The page says **No passages yet** | Your organization has no passages, or all of them are archived. | Click **New passage**, or **Add to library** on a starter. Turn on **Show archived** to see archived ones. |
| A starter is missing from **Starter passages** | It is already in your library, added from the card or inserted while writing. | Edit your copy in the list above. |
| An archived passage reappeared under **Starter passages** | It was an added starter. Archiving your copy offers Coverbase's original again. | To keep your edits, turn on **Show archived** and **Restore** your copy. Add the starter again only if you want the original wording. |
| **Insert passage** does not offer a passage | It was archived, or your library has more than 100 passages and it sorts after the first 100. | Restore it with **Show archived**, or archive passages nobody uses. |
| The signer sees `[Company name]` or another bracketed placeholder | Placeholders are plain text and were not replaced before rendering. | Fix the text and render again. If the envelope is already out, use **Correct and resend** ([Sending for signature](/user-guides/signature-envelopes#nudging-correcting-cancelling)). |
| The signature page has lines but nothing to sign | A passage draws lines, not fields. | Place **Signature** fields on the rendered page, in step 3 of the wizard or in the template builder. |
| A table or a link came out as plain text in the PDF | Only headings, paragraphs, bold, italic, lists, quotes, rules and page breaks carry through. | Rewrite the table as a list, and spell the web address out in the text. |
| `\pagebreak` printed as text instead of starting a new page | It shares a line with other text. | Put it on a line of its own. |
| **The passage could not be saved.** or a permission error | You do not hold the create or update permission on contracts. | Ask an admin to change your role. |
| **The document could not be rendered.** | The text is longer than 200,000 characters, or the title is longer than 200. | Shorten the title or the text. |
## Related
<CardGroup>
<Card title="Signature templates" icon="file-lines" href="/user-guides/signature-templates">
Turn written paper into a template: parties, fields, publishing and versions.
</Card>
<Card title="Sending for signature" icon="paper-plane" href="/user-guides/signature-envelopes">
The send wizard, where **Write** is one of the five paper sources.
</Card>
<Card title="Bulk send" icon="users" href="/user-guides/signature-bulk-send">
Send one published template to a list of parties, one envelope each.
</Card>
<Card title="E-signature overview" icon="signature" href="/user-guides/signature-overview">
How templates, envelopes, the portal and the sealed copy fit together.
</Card>
</CardGroup>
# The signing experience
Source: https://docs.coverbase.com/user-guides/signature-signing-experience
What your counterparty sees when they open a signing link: consent, the document, adopting a signature once for every block, and the executed copy they keep. Plus how to brand it as yours.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It describes the portal from the *signer's* side, so you know what you are asking someone to do. For sending, read [envelopes](/user-guides/signature-envelopes).
</Info>
Your counterparty does not need a Coverbase account. They get an email, they open a link, and everything happens in their browser, on a phone as readily as a laptop. Nothing is downloaded and nothing is installed.
This page describes each screen they pass through, so you can tell which one a confused signer is looking at.
## What they see, in order
<Steps>
<Step title="Prove the address, if you asked for it">
Only when the envelope asks for it. **Authenticate signers' identity** sends a one-time code to the address the agreement was sent to; an **Access code** set on that recipient asks for the code you gave them out of band. Either way, signers who were not expecting it often report it as a broken link.
</Step>
<Step title="Agree to sign electronically">
Your organization's ESIGN disclosure, shown in full. Nothing on the page is writable until they accept, and the exact text they were shown is stored with their acceptance.
</Step>
<Step title="Read and fill">
The document, with their fields marked on it. Everything is saved as they go, so closing the tab loses nothing.
</Step>
<Step title="Adopt a signature">
Once. It then applies to every signature, initials and stamp block that belongs to them.
</Step>
<Step title="Finish">
A separate act from filling the last field. It commits the signature.
</Step>
</Steps>
<Note>
A party who opens their link before their turn sees the agreement but cannot act on it, with an explanation of who is ahead of them. They do not get an error, and they do not need to be told to come back later.
</Note>
A copied party passes through none of these screens. When the envelope is sent they get an email saying who sent the agreement, with the document attached as a PDF and no signing link. When every party has signed, they get the executed copy and its certificate like everyone else.
## The document
<Frame>
<img alt="Signing portal showing a document with filled and empty fields, a Next chip, the remaining counter, the right-hand tool rail and a progress bar reading six of seven done" />
</Frame>
The header names the agreement, says **Review and complete**, and marks the page a **Secure signing link**. **Finish** sits at the top right and stays grayed out until nothing of theirs is outstanding.
The field outlines carry meaning, and it is worth knowing which is which when a signer describes one to you:
| | |
| - | - |
| **Blue dashed** | Theirs, and still empty. These are what the counter is counting. |
| **Green** | Theirs, and filled. |
| **Grey dashed** | Not theirs, or filled by Coverbase. Those read **Fills automatically**. Nothing for them to do. |
Two things track how far along they are. The **N Remaining · Proceed** chip in the toolbar counts only the fields that still need them and jumps to the next one; the bar along the bottom reads *6 of 7 done* against every field they own. The **Next** chip is anchored beside the field they are on and skips anything Coverbase fills itself, so a signer is never sent to a box that refuses input.
Down the right-hand rail: **Summary** asks Coverbase to summarize the agreement, **Search** finds a phrase and marks it on the page, **Pages** opens a thumbnail rail, and **Download** and **Print** take a copy of what they are being asked to sign.
<Frame>
<img alt="Signing portal with the search panel open, a highlighted phrase on the page and a result listing the page number" />
</Frame>
## Adopting a signature
<Frame>
<img alt="Adopt Your Signature dialog with draw and type tabs, name and initials fields, and a style picker" />
</Frame>
The dialog offers **Draw** and **Type**, each only when **Accepted Signature Types** in your signing settings allows it. There is no upload option on the signing page.
Two things about this come up often in support:
**One adoption covers every block.** A signer adopts once and Coverbase applies it to each signature, initials and stamp slot that belongs to them, wherever they are in the document. They do not initial each page separately.
**It is remembered.** Reopening the dialog shows the mark they adopted rather than a blank pad, so a signer checking their own signature does not have to redraw it. Drawing a new stroke replaces it.
<Frame>
<img alt="Document showing signature, initials and stamp blocks all filled from one adoption, each captioned with the signer name and id" />
</Frame>
Every mark is captioned with who applied it and their recipient id, on screen and in the sealed PDF. That caption is burned into the executed document, so it stays in English on screen even for a signer reading a translated interface. The page they approve has to match the page they receive.
## Finishing
**Finish** commits the signature. It is a separate act from filling the last field because ESIGN requires the signer to indicate intent, and filling a box does not do that on its own.
The arrow beside **Finish** opens **Other actions**: **Finish later** (everything is already saved, so the same link picks up where they left off), **Assign to someone else**, which sends a new link to the person they name and closes theirs, **Decline to sign**, which stops the envelope rather than skipping them, and **Print & sign**.
<Frame>
<img alt="Completion screen showing fully executed, download and print buttons, who else is signing, and a preview of the signed document" />
</Frame>
The confirmation names what happens next: whether every party has signed or the agreement is still moving, and who is still to act. The link stays valid, so a signer can come back for their copy later rather than needing you to send it.
## Branding the portal
Two places control how the signing link looks to a counterparty.
<AccordionGroup>
<Accordion title="Configuration → E-signature → Portal Branding">
**Sender Name** is who the agreement appears to come from. **Portal Message** is a short line shown above the document on every signing page. Use it for a contact name, or to say which agreement this is part of.
</Accordion>
<Accordion title="Your organization's branding">
The portal uses the logo and accent color from your organization's branding settings, so a signing link matches the rest of your branding without a second configuration. Set the logo there and it appears in the portal header.
</Accordion>
<Accordion title="Signing Emails">
Your own wording for the invitation, the reminder, the completion notice, the declined notice and the verification code email. Leave a field blank and Coverbase's built-in copy is used. A subject the sender types for one envelope replaces your invitation subject for that envelope. The email a copied party gets at send always uses Coverbase's wording.
</Accordion>
</AccordionGroup>
## What to tell a signer who is stuck
<AccordionGroup>
<Accordion title="I cannot click anything">
They have not accepted the electronic signature disclosure. Nothing is writable until they do.
</Accordion>
<Accordion title="It says I cannot sign yet">
They are not the current routing step. They will be emailed when it is their turn.
</Accordion>
<Accordion title="Finish is grayed out">
A required field is still empty. The bar along the bottom says how many of their fields are done, and the **Remaining** chip takes them straight to the first one that is not.
</Accordion>
<Accordion title="It is asking for a code">
Two different codes, and which one depends on the envelope. If **Authenticate signers' identity** was on, or they came in through the envelope's portal link, which always asks, the code was emailed to the address the agreement was sent to, and the page offers **Send it again**. If you set an **Access code** on that recipient, it is the code you were meant to give them yourself. Coverbase cannot show that code again, so if it is lost, use **Correct and resend** on the envelope and set a new one.
</Accordion>
<Accordion title="The document has not appeared">
A Word source is still converting to PDF. The page resolves itself when the conversion lands; no refresh needed.
</Accordion>
</AccordionGroup>
## Related
<CardGroup>
<Card title="Sending for signature" icon="paper-plane" href="/user-guides/signature-envelopes">
Create the envelope, set identity checks, and track what is out.
</Card>
<Card title="Signature templates" icon="file-lines" href="/user-guides/signature-templates">
Field types, required and read-only switches, and the signer tooltip.
</Card>
<Card title="E-signature overview" icon="signature" href="/user-guides/signature-overview">
Signing settings: consent wording, accepted signature types, and verification.
</Card>
</CardGroup>
# Signature templates
Source: https://docs.coverbase.com/user-guides/signature-templates
Build the paper you send repeatedly once: the source document, the signing parties as roles, and the fields each role fills. Then publish it, send from it, and version it when the wording changes.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. Read the [e-signature overview](/user-guides/signature-overview) first if you have not sent an envelope before. To send without building a template, go straight to [envelopes](/user-guides/signature-envelopes).
</Info>
A template is an agreement you send more than once. The document, who signs it, and where they sign are decided once. Every envelope after that only asks you who the people are.
Templates are worth the setup for an NDA, an order form or a DPA: anything where the paper is stable and only the counterparty changes. For a negotiated one-off, skip the template and place fields on the envelope directly.
**Contracts → Templates** is the list. Each row carries the category and page count of the source document, how many parties the template asks for, how many fields are placed, and the status with its version number (`Published v2`, `Draft v3`). The version number is the quickest way to see which templates have been revised and which have never left draft.
Two buttons sit beside **New template**. **Passage Library** opens your [library of reusable passages](/user-guides/signature-passage-library) (clauses, party blocks, signature pages) for writing agreements in Coverbase. [**Bulk send**](/user-guides/signature-bulk-send) sends one published template to a list of parties, each row becoming its own envelope.
<Frame>
<img alt="Templates list showing template name, category and page count, party swatches, field count, published or draft status with version, and last edited date" />
</Frame>
## Parties are roles, not people
A template does not know that Marcus Webb signs your NDAs. It knows there is a **Vendor signatory**, and that the signature block on page 3 belongs to whoever fills that seat.
That separation is what makes a template reusable, and it also makes re-ordering safe. Fields are attached to the role, so swapping who sits in a seat keeps every placement they own.
<Frame>
<img alt="Template builder showing signing parties, the field palette, a document still converting to PDF, and the empty field inspector" />
</Frame>
The header carries the version badge, the page, field and party counts, and the three things you can do with the template: **Preview as signer**, **Save draft** and **Publish template**.
## Create a template
<Steps>
<Step title="Open Contracts → Templates and pick New template">
A template needs its source document before anything can be placed on it, so the document is chosen here.
</Step>
<Step title="Name it, and say when its envelopes expire">
**Template name** is what senders pick from. **Category** groups the list. **Default expiration** is optional: switch it on and envelopes sent from this template start at that many days instead of your organization's default. Leave it off and the organization default applies.
</Step>
<Step title="Choose the paper">
**From a document** picks from your document library, **From a contract** picks a document already attached to a contract, and **Upload** takes a file from your machine. **Write** lets you write the agreement in Coverbase, inserting passages from your library, and renders it to a PDF. A template is laid out against exactly one document.
</Step>
</Steps>
<Frame>
<img alt="New Template dialog with name, category, description, default expiration and source document picker" />
</Frame>
<Note>
Word files are converted to PDF before fields can be placed, which takes a few seconds. The builder tells you it is preparing the document and the canvas fills in when the conversion lands.
</Note>
## Add the signing parties
Use **+** beside **Signing Parties** to add a role, and click a role's name to rename it. Give roles the name of the job, not the person: "Vendor signatory", "Finance approver", "Redpoint counsel". A sender filling seats reads these names and needs to know who belongs in each one.
The role you have selected is the one you are placing fields for. The bar above the document says so, and the field color follows it.
## Place the fields
Drag a field from the palette onto the page, or click it to drop one where you are looking. Drag its edges to resize, and drag the field itself to move it. Selecting a field opens the inspector on the right.
The bar above the document reads **Placing fields for** and names the party, with a running count of how many fields they own. The parties list carries the same counts, so an empty seat is obvious before you send anything.
<Frame>
<img alt="Document canvas with company, contract value, effective date, signature, date signed, printed name and title fields placed in three party colors" />
</Frame>
<Frame>
<img alt="Field inspector panel showing assigned party, label, page and position, required, read only and anchor to text toggles, and a signer tooltip" />
</Frame>
**Assigned To** moves a field to a different party without redrawing it. **Label** is the name that appears in the box and in the envelope's field list, so name it what it holds: "Job title", not "Text 3". Page, width, height and position are given as percentages, which is how you line two fields up exactly rather than by eye.
Three switches decide behavior:
| | |
| - | - |
| **Required** | The signer cannot finish while it is empty. |
| **Read only** | Shown to the signer, filled in for them. Use it for a value you are stating, not asking for. |
| **Anchor to text instead** | Binds the field to a phrase in the document rather than to a coordinate, for paper whose pagination moves between versions. |
**Tooltip for the signer** is the hint they see on hover. Add one wherever a field's label is not self-explanatory.
### What the field types do
<AccordionGroup>
<Accordion title="Marks: Signature, Initial, Stamp">
The three the signer applies rather than types. A signer adopts one mark and it fills every slot it covers, so an agreement with initials on every page asks for the mark once. Each slot is attributed in the sealed PDF with the signer's name and recipient id.
</Accordion>
<Accordion title="Filled by the engine: Date signed, Full name, First name, Last name, Email, Note">
Coverbase writes these at the moment of signing. They are placed like any other field but are never presented to the signer as something to complete, and they render read-only in the portal. Do not mark them required and expect a signer to act on them; there is nothing for them to do.
</Accordion>
<Accordion title="Filled by the signer: Text, Number, Date, Title, Company">
Free entry, with validation available in the inspector. **Company** is special: Coverbase pre-fills it from the vendor the envelope is filed against, and the signer can correct it. An envelope with no vendor still asks for it.
</Accordion>
<Accordion title="Choices: Checkbox, Dropdown, Country">
A checkbox is a single opt-in. A dropdown takes a list of options in the inspector; the portal only accepts a listed value, so a signer cannot type something you did not offer. **Country** is a dropdown that starts with every country listed, which you can trim to the ones your agreement covers.
</Accordion>
</AccordionGroup>
<Tip>
**Preview as signer** in the header shows the template the way a counterparty will see it, with each role's fields in that role's turn. It is the fastest way to catch a field placed on the wrong party.
</Tip>
## Publish it
**Save draft** keeps your work without making the template available to senders. **Publish template** makes it selectable in the send wizard.
Publishing does not lock anything. You can keep editing a published template in place until an envelope goes out from it: the header then offers **Save changes** instead of the two buttons.
## Versioning: what freezes, and when
What locks a template is the first envelope sent from it, not publishing it.
From that point the version is cited in an audit chain, because an envelope's certificate records which template version it came from. Changing the template underneath would make that record wrong. The header changes to **Edit as new version**, and choosing it forks the template into a new draft version. The earlier version stays available to senders until you publish the new one. Publishing it archives the earlier version, so senders only ever pick the newest. Sent envelopes keep pointing at the version they cited.
<Frame>
<img alt="Template builder header showing Edit as new version on a template that envelopes have been sent from" />
</Frame>
| | |
| - | - |
| **Draft** | Not available to senders. Edit freely. |
| **Published, never sent** | Available to senders. Still edit in place, with **Save changes**. |
| **Published, sent from** | Frozen. Editing forks a new version. |
| **Archived** | Hidden from the send wizard and from bulk send. A version is archived automatically when a newer version of it is published. Existing envelopes are unaffected. |
<Warning>
Opening the send wizard against a template saves nothing until you send, so abandoning it neither leaves a draft behind nor freezes the template. Only a sent envelope freezes it.
</Warning>
## Sending from a template
Templates appear in the send wizard's **From a template** tab. Picking one copies its roles in as empty seats and its field layout onto the envelope.
The copy is by value, not by reference. Editing the template afterwards does not change envelopes already created from it, so you can keep improving a template without affecting agreements that are already out.
If the template set its own **Default expiration**, the wizard starts there; otherwise it starts at your organization's default. Either way the sender can change it before sending. A [bulk send](/user-guides/signature-bulk-send) uses the template's **Default expiration** for every envelope it makes, with the same fallback.
The rest of that flow is [envelopes](/user-guides/signature-envelopes).
## Related
<CardGroup>
<Card title="E-signature overview" icon="signature" href="/user-guides/signature-overview">
How templates, envelopes, the portal and the executed copy fit together.
</Card>
<Card title="Sending for signature" icon="paper-plane" href="/user-guides/signature-envelopes">
Create an envelope from a template, name who signs, and track it to an executed copy.
</Card>
<Card title="The signing experience" icon="pen-nib" href="/user-guides/signature-signing-experience">
What a counterparty sees when they open the fields you placed.
</Card>
<Card title="The passage library" icon="book" href="/user-guides/signature-passage-library">
Reuse clauses, party blocks and signature pages when you write an agreement in Coverbase.
</Card>
<Card title="Bulk send" icon="users" href="/user-guides/signature-bulk-send">
Send one published template to a list of parties, one envelope per row.
</Card>
</CardGroup>
# Andorra
Source: https://docs.coverbase.com/user-guides/supplier-countries/ad
What Coverbase asks a supplier in Andorra for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Andorra sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Andorra. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Andorra validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# United Arab Emirates
Source: https://docs.coverbase.com/user-guides/supplier-countries/ae
What Coverbase asks a supplier in the United Arab Emirates for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in the United Arab Emirates sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | up to 4 characters, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | up to 21 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for the United Arab Emirates. It is 23 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax Registration Number | Required | 15 characters, digits only | 15 digits. |
## Where these rules come from
Oracle Fusion Cash Management 26c AE validations; FTA TRN length.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Albania
Source: https://docs.coverbase.com/user-guides/supplier-countries/al
What Coverbase asks a supplier in Albania for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Albania sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Albania. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Albania validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Argentina
Source: https://docs.coverbase.com/user-guides/supplier-countries/ar
What Coverbase asks a supplier in Argentina for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Argentina sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | up to 22 characters | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Argentina. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Argentina validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Austria
Source: https://docs.coverbase.com/user-guides/supplier-countries/at
What Coverbase asks a supplier in Austria for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Austria sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | 5 characters, digits only | |
| Branch code | Optional | 5 characters, digits only | |
| Account number | Required | 4 to 11 characters, digits only | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Austria. It is 20 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Austria validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Australia
Source: https://docs.coverbase.com/user-guides/supplier-countries/au
What Coverbase asks a supplier in Australia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Australia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| BSB | Required | 6 characters, digits only | 6 digits, for example, 062-000. |
| Account number | Required | 5 to 10 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| Intermediary bank name | Optional | up to 60 characters | |
| Intermediary SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, CHASUS33. |
| Account number at the intermediary bank | Optional | up to 34 characters | |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Australia. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| ABN | Required | 11 characters, digits only, ABN weighted checksum | 11 digits. |
After a registration is saved, Coverbase checks it against the Australian Business Register in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* A supplier's primary address must be a street address. A PO box, GPO box, locked bag or private bag is rejected there; a remittance address may still be one.
## Where these rules come from
Oracle Fusion Cash Management 26c AU validations; ABR ABN checksum; customer policy for the PO box rule.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Azerbaijan
Source: https://docs.coverbase.com/user-guides/supplier-countries/az
What Coverbase asks a supplier in Azerbaijan for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Azerbaijan sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Azerbaijan. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Azerbaijan validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Bosnia and Herzegovina
Source: https://docs.coverbase.com/user-guides/supplier-countries/ba
What Coverbase asks a supplier in Bosnia and Herzegovina for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Bosnia and Herzegovina sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Bosnia and Herzegovina. It is 20 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Bosnia and Herzegovina validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Belgium
Source: https://docs.coverbase.com/user-guides/supplier-countries/be
What Coverbase asks a supplier in Belgium for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Belgium sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | 12 characters, digits only | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Belgium. It is 16 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Belgium validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Bulgaria
Source: https://docs.coverbase.com/user-guides/supplier-countries/bg
What Coverbase asks a supplier in Bulgaria for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Bulgaria sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | up to 20 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Bulgaria. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| UIC (BULSTAT) | Required | 9 to 13 characters, digits only, UIC check digit | 9 digits for a company, 13 for a branch. |
| VAT number | Suggested | 11 to 12 characters, letters and digits | |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c BG validations.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Bahrain
Source: https://docs.coverbase.com/user-guides/supplier-countries/bh
What Coverbase asks a supplier in Bahrain for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Bahrain sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Bahrain. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Bahrain validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Saint Barthelemy
Source: https://docs.coverbase.com/user-guides/supplier-countries/bl
What Coverbase asks a supplier in Saint Barthelemy for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Saint Barthelemy sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Saint Barthelemy. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Saint Barthelemy validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Brazil
Source: https://docs.coverbase.com/user-guides/supplier-countries/br
What Coverbase asks a supplier in Brazil for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Brazil sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | up to 3 characters, digits only | Up to 3 digits; zero-padded. |
| Agência | Required | up to 5 characters, digits only | |
| Account number | Required | up to 20 characters | |
| Check digit | Required | 1 characters, digits only | The digit after the hyphen in your account number, for example, the 5 in 12345-5. |
| Company code | Optional | up to 15 characters, digits only | |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Required | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Brazil. It is 29 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| CNPJ | Required | 14 characters, digits only, CNPJ check digits | 14 digits, for example, 11.222.333/0001-81. |
After a registration is saved, Coverbase checks it against Receita Federal in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Additional details
Brazil collects a few fields that other countries do not.
| Field | Requirement | Format | Notes |
| - | - | - | - |
| State registration (Inscrição Estadual) | Suggested | up to 20 characters | Enter the state registration, or "ISENTO" if exempt. |
| Municipal registration | Optional | up to 20 characters | |
| CNAE code | Suggested | no length limit, digits only | 7 digits, for example, 6201501. |
| Tax regime | Suggested | no length limit, one of: simples\_nacional, lucro\_presumido, lucro\_real | |
| ICMS taxpayer | Suggested | no length limit | |
| ISS taxpayer | Suggested | no length limit | |
| Withholding categories | Optional | no length limit, one of: irrf, pis, cofins, csll | |
| Registration type (Tipo de Inscrição) | Suggested | no length limit, one of: cnpj, cpf | |
| Registration number (Número da Inscrição) | Suggested | up to 14 characters, digits only | The registration digits only, without punctuation. |
| Registration branch (Filial de inscrição) | Optional | 4 characters, digits only | The 4-digit branch inside a CNPJ, for example, 0001. |
| Registration check digits (Dígito da inscrição) | Optional | 2 characters, digits only | The 2 check digits at the end of a CNPJ. |
| Supplier taxpayer type (Tipo de Contribuinte do Fornecedor) | Suggested | no length limit, one of: contribuinte\_icms, contribuinte\_isento, nao\_contribuinte | |
## Country rules
* Postal codes are checked against the national format. A postal code that does not match produces a warning, not a rejection.
## Where these rules come from
Oracle Fusion Cash Management 26c BR validations.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Belarus
Source: https://docs.coverbase.com/user-guides/supplier-countries/by
What Coverbase asks a supplier in Belarus for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Belarus sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Belarus. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Belarus validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Canada
Source: https://docs.coverbase.com/user-guides/supplier-countries/ca
What Coverbase asks a supplier in Canada for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Canada sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Institution number | Required | 3 characters, digits only | 3 digits, for example, 003 for RBC. |
| Transit number | Required | 5 characters, digits only | 5 digits, the branch that holds the account. |
| Account number | Required | up to 12 characters | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Canada. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Business Number (BN) | Required | 9 to 15 characters, letters and digits | 9 digits, optionally followed by a program account suffix (for example, RT0001). |
## Country rules
* Postal codes are checked against the national format. A postal code that does not match produces a warning, not a rejection.
## Where these rules come from
Oracle Fusion Cash Management 26c CA validations; Payments Canada routing number (3-digit institution, 5-digit transit) split into its two fields.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Switzerland
Source: https://docs.coverbase.com/user-guides/supplier-countries/ch
What Coverbase asks a supplier in Switzerland for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Switzerland sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | 3 to 5 characters, digits only | |
| Branch code | Optional | 3 to 9 characters, digits only | |
| Account number | Required | up to 17 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Switzerland. It is 21 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| UID | Required | 12 characters, letters and digits, UID check digit | CHE followed by 9 digits. |
After a registration is saved, Coverbase checks it against the Swiss UID register in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c CH validations; BFS UID checksum.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Côte d'Ivoire
Source: https://docs.coverbase.com/user-guides/supplier-countries/ci
What Coverbase asks a supplier in Côte d'Ivoire for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Côte d'Ivoire sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | up to 5 characters, digits only | |
| Branch code | Optional | up to 5 characters, digits only | |
| Account number | Required | up to 20 characters, letters and digits | |
| Check digit | Optional | 2 characters, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Côte d'Ivoire. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Taxpayer account number | Suggested | 6 to 20 characters, letters and digits | |
## Where these rules come from
Oracle Fusion Cash Management 26c CI validations; BCEAO RIB structure.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Chile
Source: https://docs.coverbase.com/user-guides/supplier-countries/cl
What Coverbase asks a supplier in Chile for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Chile sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | 3 characters, digits only | 3 digits. |
| Branch code | Optional | 3 characters, digits only | 3 digits, where the bank issues one. |
| Account number | Required | 4 to 20 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Chile does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| RUT | Required | 8 to 9 characters, letters and digits, RUT verification digit | Body and check digit, for example, 76.086.428-5. The check digit may be K. |
## Country rules
* Postal codes are checked against the national format. A postal code that does not match produces a warning, not a rejection.
## Where these rules come from
Bank and branch codes per the customer's finance configuration (3 digits each); SII RUT modulo-11 check digit. Account-number length is issuer-specific in Chile, so the window is wide by design. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# China
Source: https://docs.coverbase.com/user-guides/supplier-countries/cn
What Coverbase asks a supplier in China for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in China sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| CNAPS code | Optional | 12 characters, digits only | 12 digits, if known. |
| Account number | Required | 8 to 30 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| Intermediary bank name | Optional | up to 60 characters | |
| Intermediary SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, CHASUS33. |
| Account number at the intermediary bank | Optional | up to 34 characters | |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Required | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
China does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Unified Social Credit Code | Required | 18 characters, letters and digits, unified social credit code checksum | 18 characters. |
## Where these rules come from
PBoC CNAPS structure; GB 32100-2015 for the USCC. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Colombia
Source: https://docs.coverbase.com/user-guides/supplier-countries/co
What Coverbase asks a supplier in Colombia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Colombia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | up to 20 characters | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| Branch name | Optional | up to 60 characters | Required by Citibank Colombia when the 3-digit branch code is not supplied. |
| Bank's taxpayer ID (NIT) | Optional | up to 15 characters, digits only, NIT verification digit | The NIT of the bank holding the account, not the supplier's own NIT. Leave blank if it is not on the bank statement. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Colombia. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| NIT | Required | up to 15 characters, digits only, NIT verification digit | Include the verification digit, for example, 890903938-8. |
## Additional details
Colombia collects a few fields that other countries do not.
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Tax regime | Suggested | no length limit, one of: comun, simplificado, especial | |
| Fiscal responsibilities (DIAN) | Optional | no length limit, one of: O-13, O-15, O-23, O-47 | |
| ICA activity code | Optional | up to 10 characters, digits only | |
| ICA municipality (DANE code) | Optional | no length limit, digits only | 5 digits, for example, 11001 for Bogotá. |
| Gran contribuyente | Suggested | no length limit | |
| Autorretenedor | Suggested | no length limit | |
## Where these rules come from
Oracle Fusion Cash Management 26c CO validations; DIAN NIT checksum.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Costa Rica
Source: https://docs.coverbase.com/user-guides/supplier-countries/cr
What Coverbase asks a supplier in Costa Rica for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Costa Rica sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Costa Rica. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Costa Rica validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Cyprus
Source: https://docs.coverbase.com/user-guides/supplier-countries/cy
What Coverbase asks a supplier in Cyprus for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Cyprus sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Cyprus. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Cyprus validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Czech Republic
Source: https://docs.coverbase.com/user-guides/supplier-countries/cz
What Coverbase asks a supplier in Czech Republic for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Czech Republic sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Czech Republic. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Czech Republic validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Germany
Source: https://docs.coverbase.com/user-guides/supplier-countries/de
What Coverbase asks a supplier in Germany for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Germany sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bankleitzahl | Optional | 8 characters, digits only | |
| Branch code | Optional | 8 characters, digits only | |
| Account number | Required | up to 10 characters, digits only | |
| Check digit | Optional | 1 characters, digits only, German account check digit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Germany. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| VAT number (USt-IdNr.) | Required | 11 characters, letters and digits, German VAT check digit | DE followed by 9 digits. |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* The bank code and branch code must match each other.
## Where these rules come from
Oracle Fusion Cash Management 26c DE validations.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Denmark
Source: https://docs.coverbase.com/user-guides/supplier-countries/dk
What Coverbase asks a supplier in Denmark for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Denmark sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | up to 10 characters, digits only | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Denmark. It is 18 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Denmark validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Dominican Republic
Source: https://docs.coverbase.com/user-guides/supplier-countries/do
What Coverbase asks a supplier in Dominican Republic for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Dominican Republic sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Dominican Republic. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Dominican Republic validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Algeria
Source: https://docs.coverbase.com/user-guides/supplier-countries/dz
What Coverbase asks a supplier in Algeria for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Algeria sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Algeria. It is 26 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Algeria validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Estonia
Source: https://docs.coverbase.com/user-guides/supplier-countries/ee
What Coverbase asks a supplier in Estonia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Estonia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Estonia. It is 20 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Estonia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Egypt
Source: https://docs.coverbase.com/user-guides/supplier-countries/eg
What Coverbase asks a supplier in Egypt for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Egypt sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Egypt. It is 29 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Egypt validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Spain
Source: https://docs.coverbase.com/user-guides/supplier-countries/es
What Coverbase asks a supplier in Spain for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Spain sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | up to 4 characters, digits only | |
| Branch code | Required | up to 4 characters, digits only | |
| Account number | Required | 10 characters, digits only | |
| Check digit | Optional | 2 characters, digits only, Spanish dual control digits | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Spain. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| NIF / CIF | Required | 9 characters, letters and digits, NIF and CIF control character | 9 characters, for example, A58818501. |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c ES validations; CCC dual check digits.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Finland
Source: https://docs.coverbase.com/user-guides/supplier-countries/fi
What Coverbase asks a supplier in Finland for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Finland sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Optional | 6 characters, digits only | |
| Account number | Required | 8 to 14 characters, digits only, Finnish account check digit | |
| Check digit | Optional | 1 characters, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Finland. It is 18 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Business ID (Y-tunnus) | Required | 8 characters, letters and digits, Y-tunnus check digit | 7 digits plus a check digit, for example, 0201256-6. |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c FI validations; PRH Y-tunnus checksum.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Faroe Islands
Source: https://docs.coverbase.com/user-guides/supplier-countries/fo
What Coverbase asks a supplier in Faroe Islands for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Faroe Islands sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Faroe Islands. It is 18 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Faroe Islands validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# France
Source: https://docs.coverbase.com/user-guides/supplier-countries/fr
What Coverbase asks a supplier in France for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in France sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | up to 5 characters, digits only | |
| Branch code (guichet) | Required | up to 5 characters, digits only | |
| Account number | Required | up to 11 characters, letters and digits | |
| Check digit | Required | 2 characters, digits only, RIB key check | The 2-digit RIB key, the last two digits of your RIB. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for France. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| SIREN | Required | 9 characters, digits only, SIREN Luhn check | 9 digits. |
| SIRET | Optional | 14 characters, digits only, SIREN Luhn check | |
| VAT number | Suggested | 13 characters, letters and digits, French VAT key check | |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c FR validations; INSEE SIREN, DGFiP VAT key.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# United Kingdom
Source: https://docs.coverbase.com/user-guides/supplier-countries/gb
What Coverbase asks a supplier in the United Kingdom for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in the United Kingdom sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | 6 characters, digits only | |
| Sort Code | Required | 6 characters, digits only | 6 digits, for example, 04-00-04. |
| Account number | Required | 8 characters, digits only | 8 digits (a 7-digit number is zero-padded). |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| Building society roll number | Optional | up to 18 characters | |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for the United Kingdom. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Company number | Required | 8 characters, letters and digits | 8 characters, for example, 01234567 or SC123456. |
| VAT number | Suggested | 9 to 14 characters, letters and digits, UK VAT MOD-97 check | |
After a registration is saved, Coverbase checks it against Companies House and HMRC in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* Postal codes are checked against the national format. A postal code that does not match produces a warning, not a rejection.
## Where these rules come from
Oracle Fusion Cash Management 26c GB validations.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Georgia
Source: https://docs.coverbase.com/user-guides/supplier-countries/ge
What Coverbase asks a supplier in Georgia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Georgia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Georgia. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Georgia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# French Guiana
Source: https://docs.coverbase.com/user-guides/supplier-countries/gf
What Coverbase asks a supplier in French Guiana for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in French Guiana sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for French Guiana. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c French Guiana validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Ghana
Source: https://docs.coverbase.com/user-guides/supplier-countries/gh
What Coverbase asks a supplier in Ghana for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Ghana sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
The format for this country could not be confirmed against a primary source. Collection is deliberately permissive: a value that looks unusual produces a warning rather than a rejection, so a supplier with a legitimate account is never blocked.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Required | 2 characters, digits only | |
| Branch code | Required | 4 characters, digits only | |
| Account number | Required | 8 to 16 characters, digits only | Commonly 13 digits. Used for GHS payments only. |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Ghana does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| TIN | Suggested | 9 to 15 characters, letters and digits | GRA-issued TIN. |
## Where these rules come from
Bank of Ghana GhIPSS account formats; length bounds only. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
The format for this country could not be confirmed against a primary source. Collection is deliberately permissive: a value that looks unusual produces a warning rather than a rejection, so a supplier with a legitimate account is never blocked.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Gibraltar
Source: https://docs.coverbase.com/user-guides/supplier-countries/gi
What Coverbase asks a supplier in Gibraltar for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Gibraltar sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Gibraltar. It is 23 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Gibraltar validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Greenland
Source: https://docs.coverbase.com/user-guides/supplier-countries/gl
What Coverbase asks a supplier in Greenland for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Greenland sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Greenland. It is 18 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Greenland validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Guadeloupe
Source: https://docs.coverbase.com/user-guides/supplier-countries/gp
What Coverbase asks a supplier in Guadeloupe for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Guadeloupe sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Guadeloupe. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Guadeloupe validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Greece
Source: https://docs.coverbase.com/user-guides/supplier-countries/gr
What Coverbase asks a supplier in Greece for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Greece sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | 3 characters, digits only | |
| Branch code | Optional | 4 characters, digits only | |
| Account number | Required | 8 to 16 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Greece. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Greece validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Guatemala
Source: https://docs.coverbase.com/user-guides/supplier-countries/gt
What Coverbase asks a supplier in Guatemala for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Guatemala sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Guatemala. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Guatemala validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Hong Kong SAR
Source: https://docs.coverbase.com/user-guides/supplier-countries/hk
What Coverbase asks a supplier in Hong Kong SAR for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Hong Kong SAR sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Suggested | 3 characters, digits only | 3 digits. |
| Branch code | Suggested | 3 characters, digits only | 3 digits. |
| Account number | Required | 6 to 12 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Required | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Hong Kong SAR does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Business Registration Number | Required | 8 characters, digits only | 8 digits. |
## Where these rules come from
HKICL clearing code structure (3-digit bank + 3-digit branch). VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Croatia
Source: https://docs.coverbase.com/user-guides/supplier-countries/hr
What Coverbase asks a supplier in Croatia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Croatia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Croatia. It is 21 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Croatia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Hungary
Source: https://docs.coverbase.com/user-guides/supplier-countries/hu
What Coverbase asks a supplier in Hungary for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Hungary sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Hungary. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Hungary validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Indonesia
Source: https://docs.coverbase.com/user-guides/supplier-countries/id
What Coverbase asks a supplier in Indonesia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Indonesia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Suggested | 3 characters, digits only | 3 digits. |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | 10 to 16 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Indonesia does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| NPWP | Required | 15 to 16 characters, digits only | 15 digits (16 for the NIK-based format). |
## Where these rules come from
Bank Indonesia BI-FAST bank codes. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Ireland
Source: https://docs.coverbase.com/user-guides/supplier-countries/ie
What Coverbase asks a supplier in Ireland for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Ireland sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| NSC | Optional | 6 characters, digits only | |
| Branch code | Optional | 6 characters, digits only | |
| Account number | Required | 8 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Ireland. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| VAT number | Required | 8 to 11 characters, Irish VAT check character | |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* The bank code and branch code must match each other.
## Where these rules come from
Oracle Fusion Cash Management 26c IE validations.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Israel
Source: https://docs.coverbase.com/user-guides/supplier-countries/il
What Coverbase asks a supplier in Israel for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Israel sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | no length limit, digits only | |
| Branch code | Required | 3 characters, digits only | |
| Account number | Required | up to 13 characters, digits only | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Israel. It is 23 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Israel validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# India
Source: https://docs.coverbase.com/user-guides/supplier-countries/in
What Coverbase asks a supplier in India for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in India sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| IFSC Code | Suggested | 11 characters, letters and digits | 11 characters, for example, HDFC0000123. |
| Account number | Required | up to 18 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for India. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| PAN | Required | 10 characters, letters and digits | 10 characters, for example, AAAPZ1234C. |
| GSTIN | Suggested | 15 characters, letters and digits, GSTIN checksum | 15 characters. |
After a registration is saved, Coverbase checks it against the Indian GST portal in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c IN validations; RBI IFSC format.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Iraq
Source: https://docs.coverbase.com/user-guides/supplier-countries/iq
What Coverbase asks a supplier in Iraq for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Iraq sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Iraq. It is 23 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Iraq validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Iran
Source: https://docs.coverbase.com/user-guides/supplier-countries/ir
What Coverbase asks a supplier in Iran for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Iran sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Iran. It is 26 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Iran validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Iceland
Source: https://docs.coverbase.com/user-guides/supplier-countries/is
What Coverbase asks a supplier in Iceland for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Iceland sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | 4 characters, digits only | |
| Branch code | Optional | 4 characters, digits only | |
| Account number | Required | up to 18 characters, digits only | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Iceland. It is 26 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Country rules
* The bank code and branch code must match each other.
## Where these rules come from
Oracle Fusion Cash Management 26c Iceland validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Italy
Source: https://docs.coverbase.com/user-guides/supplier-countries/it
What Coverbase asks a supplier in Italy for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Italy sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| ABI | Required | up to 5 characters, digits only | |
| CAB | Required | up to 5 characters, digits only | |
| Account number | Required | 12 characters, letters and digits | |
| Check digit | Optional | 1 characters, letters only, CIN control character | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Italy. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Partita IVA | Required | 11 characters, digits only, Partita IVA check digit | 11 digits. |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c IT validations; ABI CIN table.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Jordan
Source: https://docs.coverbase.com/user-guides/supplier-countries/jo
What Coverbase asks a supplier in Jordan for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Jordan sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Jordan. It is 30 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Jordan validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Japan
Source: https://docs.coverbase.com/user-guides/supplier-countries/jp
What Coverbase asks a supplier in Japan for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Japan sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | 4 characters, digits only | 4 digits. |
| Branch code | Required | 3 characters, digits only | 3 digits. |
| Account holder name (half-width katakana) | Required | up to 48 characters | Half-width katakana, for example, ｶﾌﾞｼｷｶﾞｲｼｬ. |
| Bank name (Japanese) | Suggested | up to 40 characters | Full-width characters only. |
| Branch name (Japanese) | Suggested | up to 40 characters | Full-width characters only. |
| Account number | Required | up to 8 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| Deposit type | Required | no length limit, one of: futsu, toza, chochiku | Futsu (ordinary), Toza (current) or Chochiku (savings). |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
### IBAN
An IBAN is optional for Japan. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Corporate Number | Required | 13 characters, digits only, Japanese corporate number check digit | 13 digits. |
After a registration is saved, Coverbase checks it against Japan's National Tax Agency in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* Postal codes are checked against the national format. A postal code that does not match produces a warning, not a rejection.
## Where these rules come from
Oracle Fusion Cash Management 26c JP validations; NTA corporate number spec.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# South Korea
Source: https://docs.coverbase.com/user-guides/supplier-countries/kr
What Coverbase asks a supplier in South Korea for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in South Korea sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Suggested | 3 characters, digits only | 3 digits. |
| Account number | Required | 10 to 16 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
South Korea does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Business Registration Number | Required | 10 characters, digits only, Korean business registration checksum | 10 digits, for example, 120-81-47521. |
## Where these rules come from
KFTC bank codes; NTS business registration checksum. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Kuwait
Source: https://docs.coverbase.com/user-guides/supplier-countries/kw
What Coverbase asks a supplier in Kuwait for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Kuwait sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | up to 22 characters | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Kuwait. It is 30 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Kuwait validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Kazakhstan
Source: https://docs.coverbase.com/user-guides/supplier-countries/kz
What Coverbase asks a supplier in Kazakhstan for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Kazakhstan sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Kazakhstan. It is 20 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Kazakhstan validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Lebanon
Source: https://docs.coverbase.com/user-guides/supplier-countries/lb
What Coverbase asks a supplier in Lebanon for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Lebanon sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Lebanon. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Lebanon validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Saint Lucia
Source: https://docs.coverbase.com/user-guides/supplier-countries/lc
What Coverbase asks a supplier in Saint Lucia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Saint Lucia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Saint Lucia. It is 32 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Saint Lucia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Liechtenstein
Source: https://docs.coverbase.com/user-guides/supplier-countries/li
What Coverbase asks a supplier in Liechtenstein for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Liechtenstein sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Liechtenstein. It is 21 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Liechtenstein validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Lithuania
Source: https://docs.coverbase.com/user-guides/supplier-countries/lt
What Coverbase asks a supplier in Lithuania for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Lithuania sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Lithuania. It is 20 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Lithuania validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Luxembourg
Source: https://docs.coverbase.com/user-guides/supplier-countries/lu
What Coverbase asks a supplier in Luxembourg for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Luxembourg sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | 3 characters, digits only | |
| Branch code | Optional | 3 characters, digits only | |
| Account number | Required | up to 13 characters | |
| Check digit | Optional | 2 characters, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Luxembourg. It is 20 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Country rules
* The bank code and branch code must match each other.
## Where these rules come from
Oracle Fusion Cash Management 26c Luxembourg validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Latvia
Source: https://docs.coverbase.com/user-guides/supplier-countries/lv
What Coverbase asks a supplier in Latvia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Latvia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Latvia. It is 21 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Latvia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Morocco
Source: https://docs.coverbase.com/user-guides/supplier-countries/ma
What Coverbase asks a supplier in Morocco for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Morocco sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Morocco. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Morocco validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Monaco
Source: https://docs.coverbase.com/user-guides/supplier-countries/mc
What Coverbase asks a supplier in Monaco for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Monaco sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Monaco. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Monaco validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Moldova
Source: https://docs.coverbase.com/user-guides/supplier-countries/md
What Coverbase asks a supplier in Moldova for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Moldova sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Moldova. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Moldova validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Montenegro
Source: https://docs.coverbase.com/user-guides/supplier-countries/me
What Coverbase asks a supplier in Montenegro for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Montenegro sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Montenegro. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Montenegro validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Saint Martin (French Section)
Source: https://docs.coverbase.com/user-guides/supplier-countries/mf
What Coverbase asks a supplier in Saint Martin (French Section) for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Saint Martin (French Section) sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Saint Martin (French Section). It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Saint Martin (French Section) validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Martinique
Source: https://docs.coverbase.com/user-guides/supplier-countries/mq
What Coverbase asks a supplier in Martinique for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Martinique sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Martinique. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Martinique validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Mauritania
Source: https://docs.coverbase.com/user-guides/supplier-countries/mr
What Coverbase asks a supplier in Mauritania for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Mauritania sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Mauritania. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Mauritania validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Malta
Source: https://docs.coverbase.com/user-guides/supplier-countries/mt
What Coverbase asks a supplier in Malta for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Malta sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Malta. It is 31 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Malta validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Mauritius
Source: https://docs.coverbase.com/user-guides/supplier-countries/mu
What Coverbase asks a supplier in Mauritius for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Mauritius sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | up to 20 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Mauritius. It is 30 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax Account Number (TAN) | Suggested | 8 characters, digits only | 8 digits. |
## Where these rules come from
Oracle Fusion Cash Management 26c MU validations; MRA TAN length.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Mexico
Source: https://docs.coverbase.com/user-guides/supplier-countries/mx
What Coverbase asks a supplier in Mexico for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Mexico sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Read from the CLABE | not entered separately | |
| Branch code | Read from the CLABE | not entered separately | |
| Account number | Read from the CLABE | not entered separately | |
| Check digit | Read from the CLABE | not entered separately | |
| CLABE | Required | 18 characters, digits only, CLABE check digit | 18 digits: 3-digit bank code, 3-digit branch, 11-digit account, check digit. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Mexico does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| RFC | Required | 12 to 13 characters, letters and digits, RFC control character | 12 characters for companies, 13 for individuals. |
## Where these rules come from
Oracle Fusion Cash Management 26c MX validations; Banxico CLABE spec. The CLABE is required and the account number is not: the CLABE contains the bank, the branch and the account, and is what Mexican suppliers quote.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Malaysia
Source: https://docs.coverbase.com/user-guides/supplier-countries/my
What Coverbase asks a supplier in Malaysia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Malaysia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch number | Suggested | 7 characters, digits only | |
| Account number | Required | 10 to 16 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Malaysia does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax Identification Number | Required | 10 to 14 characters, letters and digits | Prefix letter(s) followed by digits, for example, C1234567890. |
## Where these rules come from
PayNet RENTAS account formats; LHDN TIN prefixes. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Nigeria
Source: https://docs.coverbase.com/user-guides/supplier-countries/ng
What Coverbase asks a supplier in Nigeria for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Nigeria sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Required | 3 characters, digits only | 3-digit CBN institution code. |
| Branch code | Suggested | 5 characters, digits only | |
| Account number | Required | 10 characters, digits only, NUBAN check digit | 10-digit NUBAN. |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Nigeria does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| TIN | Suggested | 8 to 17 characters | |
## Where these rules come from
CBN NUBAN specification (weights 3,7,3 over bank code + serial).
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Netherlands
Source: https://docs.coverbase.com/user-guides/supplier-countries/nl
What Coverbase asks a supplier in the Netherlands for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in the Netherlands sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | up to 10 characters, letters and digits, Dutch eleven-proof check | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for the Netherlands. It is 18 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| KvK number | Required | 8 characters, digits only | 8 digits. |
| BTW-id | Suggested | 14 characters, letters and digits, Dutch VAT MOD-97 check | |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* Postal codes are checked against the national format. A postal code that does not match produces a warning, not a rejection.
## Where these rules come from
Oracle Fusion Cash Management 26c NL validations.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Norway
Source: https://docs.coverbase.com/user-guides/supplier-countries/no
What Coverbase asks a supplier in Norway for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Norway sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | 11 characters, digits only, no\_mod11 checksum | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Norway. It is 15 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Norway validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# New Zealand
Source: https://docs.coverbase.com/user-guides/supplier-countries/nz
What Coverbase asks a supplier in New Zealand for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in New Zealand sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | 2 characters, digits only | |
| Branch code | Required | 4 characters, digits only | |
| Account number | Required | 7 to 8 characters, digits only | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for New Zealand. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c New Zealand validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Oman
Source: https://docs.coverbase.com/user-guides/supplier-countries/om
What Coverbase asks a supplier in Oman for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Oman sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | up to 20 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Oman. It is 23 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| VAT identification number | Suggested | 12 characters, letters and digits | |
## Where these rules come from
SWIFT IBAN registry (OM, 23 characters); Oman Tax Authority VATIN format. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Supplier countries
Source: https://docs.coverbase.com/user-guides/supplier-countries/overview
What Coverbase asks a supplier for in each of the countries it validates.
[User guides](/user-guides/overview)
Coverbase collects supplier bank details, addresses, and tax registrations
according to the country the details belong to. Each country has its own set of
fields, its own formats, and its own checks, and this section documents what
each one asks for.
Use these pages when you want to know what a supplier in a given country will
be asked for before you send them a request, or when you are looking at a
warning on a submitted record and want to know what produced it.
For how collection and review work, see the
[Supplier information guide](/user-guides/supplier-information).
## Countries
| Country | IBAN | Tax registrations | Rule confidence |
| - | - | - | - |
| [Albania](/user-guides/supplier-countries/al) | Optional | Tax ID / VAT number | High |
| [Algeria](/user-guides/supplier-countries/dz) | Optional | Tax ID / VAT number | High |
| [Andorra](/user-guides/supplier-countries/ad) | Optional | Tax ID / VAT number | High |
| [Argentina](/user-guides/supplier-countries/ar) | Optional | Tax ID / VAT number | High |
| [Australia](/user-guides/supplier-countries/au) | Optional | ABN | High |
| [Austria](/user-guides/supplier-countries/at) | Required | Tax ID / VAT number | High |
| [Azerbaijan](/user-guides/supplier-countries/az) | Optional | Tax ID / VAT number | High |
| [Bahrain](/user-guides/supplier-countries/bh) | Optional | Tax ID / VAT number | High |
| [Belarus](/user-guides/supplier-countries/by) | Optional | Tax ID / VAT number | High |
| [Belgium](/user-guides/supplier-countries/be) | Required | Tax ID / VAT number | High |
| [Bosnia and Herzegovina](/user-guides/supplier-countries/ba) | Required | Tax ID / VAT number | High |
| [Brazil](/user-guides/supplier-countries/br) | Optional | CNPJ | High |
| [British Virgin Islands](/user-guides/supplier-countries/vg) | Optional | Tax ID / VAT number | High |
| [Bulgaria](/user-guides/supplier-countries/bg) | Required | UIC (BULSTAT), VAT number | High |
| [Canada](/user-guides/supplier-countries/ca) | Optional | Business Number (BN) | High |
| [Chile](/user-guides/supplier-countries/cl) | Not used | RUT | Medium |
| [China](/user-guides/supplier-countries/cn) | Not used | Unified Social Credit Code | Medium |
| [Colombia](/user-guides/supplier-countries/co) | Optional | NIT | High |
| [Costa Rica](/user-guides/supplier-countries/cr) | Optional | Tax ID / VAT number | High |
| [Croatia](/user-guides/supplier-countries/hr) | Required | Tax ID / VAT number | High |
| [Cyprus](/user-guides/supplier-countries/cy) | Required | Tax ID / VAT number | High |
| [Czech Republic](/user-guides/supplier-countries/cz) | Required | Tax ID / VAT number | High |
| [Côte d'Ivoire](/user-guides/supplier-countries/ci) | Optional | Taxpayer account number | Medium |
| [Denmark](/user-guides/supplier-countries/dk) | Required | Tax ID / VAT number | High |
| [Dominican Republic](/user-guides/supplier-countries/do) | Optional | Tax ID / VAT number | High |
| [Egypt](/user-guides/supplier-countries/eg) | Optional | Tax ID / VAT number | High |
| [El Salvador](/user-guides/supplier-countries/sv) | Optional | Tax ID / VAT number | High |
| [Estonia](/user-guides/supplier-countries/ee) | Required | Tax ID / VAT number | High |
| [Faroe Islands](/user-guides/supplier-countries/fo) | Optional | Tax ID / VAT number | High |
| [Finland](/user-guides/supplier-countries/fi) | Required | Business ID (Y-tunnus) | High |
| [France](/user-guides/supplier-countries/fr) | Required | SIREN, SIRET, VAT number | High |
| [French Guiana](/user-guides/supplier-countries/gf) | Required | Tax ID / VAT number | High |
| [Georgia](/user-guides/supplier-countries/ge) | Optional | Tax ID / VAT number | High |
| [Germany](/user-guides/supplier-countries/de) | Required | VAT number (USt-IdNr.) | High |
| [Ghana](/user-guides/supplier-countries/gh) | Not used | TIN | Low |
| [Gibraltar](/user-guides/supplier-countries/gi) | Required | Tax ID / VAT number | High |
| [Greece](/user-guides/supplier-countries/gr) | Required | Tax ID / VAT number | High |
| [Greenland](/user-guides/supplier-countries/gl) | Optional | Tax ID / VAT number | High |
| [Guadeloupe](/user-guides/supplier-countries/gp) | Required | Tax ID / VAT number | High |
| [Guatemala](/user-guides/supplier-countries/gt) | Optional | Tax ID / VAT number | High |
| [Hong Kong SAR](/user-guides/supplier-countries/hk) | Not used | Business Registration Number | Medium |
| [Hungary](/user-guides/supplier-countries/hu) | Required | Tax ID / VAT number | High |
| [Iceland](/user-guides/supplier-countries/is) | Required | Tax ID / VAT number | High |
| [India](/user-guides/supplier-countries/in) | Optional | PAN, GSTIN | High |
| [Indonesia](/user-guides/supplier-countries/id) | Not used | NPWP | Medium |
| [Iran](/user-guides/supplier-countries/ir) | Optional | Tax ID / VAT number | High |
| [Iraq](/user-guides/supplier-countries/iq) | Optional | Tax ID / VAT number | High |
| [Ireland](/user-guides/supplier-countries/ie) | Required | VAT number | High |
| [Israel](/user-guides/supplier-countries/il) | Optional | Tax ID / VAT number | High |
| [Italy](/user-guides/supplier-countries/it) | Required | Partita IVA | High |
| [Japan](/user-guides/supplier-countries/jp) | Optional | Corporate Number | High |
| [Jordan](/user-guides/supplier-countries/jo) | Optional | Tax ID / VAT number | High |
| [Kazakhstan](/user-guides/supplier-countries/kz) | Optional | Tax ID / VAT number | High |
| [Kosovo](/user-guides/supplier-countries/xk) | Optional | Tax ID / VAT number | High |
| [Kuwait](/user-guides/supplier-countries/kw) | Optional | Tax ID / VAT number | High |
| [Latvia](/user-guides/supplier-countries/lv) | Required | Tax ID / VAT number | High |
| [Lebanon](/user-guides/supplier-countries/lb) | Optional | Tax ID / VAT number | High |
| [Liechtenstein](/user-guides/supplier-countries/li) | Required | Tax ID / VAT number | High |
| [Lithuania](/user-guides/supplier-countries/lt) | Required | Tax ID / VAT number | High |
| [Luxembourg](/user-guides/supplier-countries/lu) | Required | Tax ID / VAT number | High |
| [Malaysia](/user-guides/supplier-countries/my) | Not used | Tax Identification Number | Medium |
| [Malta](/user-guides/supplier-countries/mt) | Required | Tax ID / VAT number | High |
| [Martinique](/user-guides/supplier-countries/mq) | Required | Tax ID / VAT number | High |
| [Mauritania](/user-guides/supplier-countries/mr) | Optional | Tax ID / VAT number | High |
| [Mauritius](/user-guides/supplier-countries/mu) | Required | Tax Account Number (TAN) | Medium |
| [Mayotte](/user-guides/supplier-countries/yt) | Required | Tax ID / VAT number | High |
| [Mexico](/user-guides/supplier-countries/mx) | Not used | RFC | High |
| [Moldova](/user-guides/supplier-countries/md) | Optional | Tax ID / VAT number | High |
| [Monaco](/user-guides/supplier-countries/mc) | Required | Tax ID / VAT number | High |
| [Montenegro](/user-guides/supplier-countries/me) | Required | Tax ID / VAT number | High |
| [Morocco](/user-guides/supplier-countries/ma) | Optional | Tax ID / VAT number | High |
| [Netherlands](/user-guides/supplier-countries/nl) | Required | KvK number, BTW-id | High |
| [New Zealand](/user-guides/supplier-countries/nz) | Optional | Tax ID / VAT number | High |
| [Nigeria](/user-guides/supplier-countries/ng) | Not used | TIN | High |
| [Norway](/user-guides/supplier-countries/no) | Required | Tax ID / VAT number | High |
| [Oman](/user-guides/supplier-countries/om) | Required | VAT identification number | Medium |
| [Pakistan](/user-guides/supplier-countries/pk) | Optional | Tax ID / VAT number | High |
| [Palestine](/user-guides/supplier-countries/ps) | Optional | Tax ID / VAT number | High |
| [Peru](/user-guides/supplier-countries/pe) | Not used | RUC | Medium |
| [Philippines](/user-guides/supplier-countries/ph) | Not used | TIN | Medium |
| [Poland](/user-guides/supplier-countries/pl) | Required | NIP | High |
| [Portugal](/user-guides/supplier-countries/pt) | Required | NIF | High |
| [Qatar](/user-guides/supplier-countries/qa) | Optional | Tax ID / VAT number | High |
| [Reunion](/user-guides/supplier-countries/re) | Required | Tax ID / VAT number | High |
| [Romania](/user-guides/supplier-countries/ro) | Required | Tax ID / VAT number | High |
| [Saint Barthelemy](/user-guides/supplier-countries/bl) | Required | Tax ID / VAT number | High |
| [Saint Lucia](/user-guides/supplier-countries/lc) | Optional | Tax ID / VAT number | High |
| [Saint Martin (French Section)](/user-guides/supplier-countries/mf) | Required | Tax ID / VAT number | High |
| [Saint Pierre and Miquelon](/user-guides/supplier-countries/pm) | Required | Tax ID / VAT number | High |
| [San Marino](/user-guides/supplier-countries/sm) | Required | Tax ID / VAT number | High |
| [Saudi Arabia](/user-guides/supplier-countries/sa) | Suggested | VAT number | High |
| [Senegal](/user-guides/supplier-countries/sn) | Optional | Tax ID / VAT number | High |
| [Serbia](/user-guides/supplier-countries/rs) | Optional | Tax ID / VAT number | High |
| [Seychelles](/user-guides/supplier-countries/sc) | Optional | Tax ID / VAT number | High |
| [Singapore](/user-guides/supplier-countries/sg) | Optional | UEN | High |
| [Slovakia](/user-guides/supplier-countries/sk) | Required | Tax ID / VAT number | High |
| [Slovenia](/user-guides/supplier-countries/si) | Required | Tax ID / VAT number | High |
| [South Africa](/user-guides/supplier-countries/za) | Not used | Income tax reference number, CIPC registration number | Medium |
| [South Korea](/user-guides/supplier-countries/kr) | Not used | Business Registration Number | Medium |
| [Spain](/user-guides/supplier-countries/es) | Required | NIF / CIF | High |
| [Sweden](/user-guides/supplier-countries/se) | Required | Organisationsnummer | High |
| [Switzerland](/user-guides/supplier-countries/ch) | Required | UID | High |
| [Thailand](/user-guides/supplier-countries/th) | Not used | Tax ID | Medium |
| [Tunisia](/user-guides/supplier-countries/tn) | Optional | Tax ID / VAT number | High |
| [Türkiye](/user-guides/supplier-countries/tr) | Required | Vergi Kimlik Numarası | High |
| [Ukraine](/user-guides/supplier-countries/ua) | Optional | Tax ID / VAT number | High |
| [United Arab Emirates](/user-guides/supplier-countries/ae) | Required | Tax Registration Number | High |
| [United Kingdom](/user-guides/supplier-countries/gb) | Required | Company number, VAT number | High |
| [United States](/user-guides/supplier-countries/us) | Optional | EIN | High |
# Peru
Source: https://docs.coverbase.com/user-guides/supplier-countries/pe
What Coverbase asks a supplier in Peru for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Peru sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Read from the CCI (interbank account code) | not entered separately | |
| Branch code | Read from the CCI (interbank account code) | not entered separately | |
| Account number | Read from the CCI (interbank account code) | not entered separately | |
| CCI (interbank account code) | Required | 20 characters, digits only | The 20-digit interbank code (CCI) on your bank statement. It already includes your bank, branch and account number. |
| Check digit | Read from the CCI (interbank account code) | not entered separately | |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Peru does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| RUC | Required | 11 characters, digits only, RUC check digit | 11 digits. |
## Where these rules come from
SBS/BCRP interbank CCI structure. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Philippines
Source: https://docs.coverbase.com/user-guides/supplier-countries/ph
What Coverbase asks a supplier in the Philippines for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in the Philippines sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | 10 to 16 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
the Philippines does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| TIN | Required | 9 to 14 characters, digits only | 9 digits, plus an optional branch code. |
## Where these rules come from
BSP PESONet/InstaPay account formats. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Pakistan
Source: https://docs.coverbase.com/user-guides/supplier-countries/pk
What Coverbase asks a supplier in Pakistan for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Pakistan sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Pakistan. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Pakistan validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Poland
Source: https://docs.coverbase.com/user-guides/supplier-countries/pl
What Coverbase asks a supplier in Poland for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Poland sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | 8 characters, digits only | |
| Branch code | Optional | 8 characters, digits only | |
| Account number | Required | 16 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Poland. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| NIP | Required | 10 characters, digits only, NIP check digit | 10 digits. |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* The bank code and branch code must match each other.
## Where these rules come from
Oracle Fusion Cash Management 26c PL validations.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Saint Pierre and Miquelon
Source: https://docs.coverbase.com/user-guides/supplier-countries/pm
What Coverbase asks a supplier in Saint Pierre and Miquelon for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Saint Pierre and Miquelon sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Saint Pierre and Miquelon. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Saint Pierre and Miquelon validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Palestine
Source: https://docs.coverbase.com/user-guides/supplier-countries/ps
What Coverbase asks a supplier in Palestine for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Palestine sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Palestine. It is 29 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Palestine validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Portugal
Source: https://docs.coverbase.com/user-guides/supplier-countries/pt
What Coverbase asks a supplier in Portugal for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Portugal sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | 4 characters, digits only | |
| Branch code | Required | 4 characters, digits only | |
| Account number | Required | up to 11 characters, digits only | |
| Check digit | Optional | 2 characters, digits only, Portuguese account check digits | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Portugal. It is 25 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| NIF | Required | 9 characters, digits only, NIF check digit | 9 digits. |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c PT validations; NIB check digits.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Qatar
Source: https://docs.coverbase.com/user-guides/supplier-countries/qa
What Coverbase asks a supplier in Qatar for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Qatar sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Qatar. It is 29 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Qatar validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Reunion
Source: https://docs.coverbase.com/user-guides/supplier-countries/re
What Coverbase asks a supplier in Reunion for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Reunion sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Reunion. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Reunion validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Romania
Source: https://docs.coverbase.com/user-guides/supplier-countries/ro
What Coverbase asks a supplier in Romania for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Romania sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Romania. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Romania validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Serbia
Source: https://docs.coverbase.com/user-guides/supplier-countries/rs
What Coverbase asks a supplier in Serbia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Serbia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Serbia. It is 22 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Serbia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Saudi Arabia
Source: https://docs.coverbase.com/user-guides/supplier-countries/sa
What Coverbase asks a supplier in Saudi Arabia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Saudi Arabia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | up to 4 characters, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | up to 25 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is suggested for Saudi Arabia. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| VAT number | Required | 15 characters, digits only | 15 digits, starting and ending with 3. |
## Where these rules come from
Oracle Fusion Cash Management 26c SA validations; ZATCA VAT structure.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Seychelles
Source: https://docs.coverbase.com/user-guides/supplier-countries/sc
What Coverbase asks a supplier in Seychelles for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Seychelles sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Seychelles. It is 31 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Seychelles validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Sweden
Source: https://docs.coverbase.com/user-guides/supplier-countries/se
What Coverbase asks a supplier in Sweden for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Sweden sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | 4 to 5 characters, digits only | |
| Branch code | Optional | 4 to 5 characters, digits only | |
| Account number | Required | up to 16 characters, digits only | |
| Check digit | Optional | 1 characters, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| Bankgiro number | Optional | 7 to 8 characters, digits only | 7 or 8 digits, for Swedish domestic payments. Used for SEK payments only. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Sweden. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Organisationsnummer | Required | 10 characters, digits only, Swedish organisation number Luhn check | 10 digits. |
After a registration is saved, Coverbase checks it against the EU VIES service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* The bank code and branch code must match each other.
## Where these rules come from
Oracle Fusion Cash Management 26c SE validations.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Singapore
Source: https://docs.coverbase.com/user-guides/supplier-countries/sg
What Coverbase asks a supplier in Singapore for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Singapore sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Required | 4 characters, digits only | 4 digits. |
| Branch code | Required | 3 characters, digits only | 3 digits. |
| Account number | Required | up to 14 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Singapore. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| UEN | Required | 9 to 10 characters, letters and digits | 9 or 10 characters, for example, 200312345A. |
After a registration is saved, Coverbase checks it against ACRA in Singapore in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Where these rules come from
Oracle Fusion Cash Management 26c SG validations. UEN check-digit algorithms are not published by ACRA, so structure only (no checksum).
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Slovenia
Source: https://docs.coverbase.com/user-guides/supplier-countries/si
What Coverbase asks a supplier in Slovenia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Slovenia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Slovenia. It is 19 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Slovenia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Slovakia
Source: https://docs.coverbase.com/user-guides/supplier-countries/sk
What Coverbase asks a supplier in Slovakia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Slovakia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Slovakia. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Slovakia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# San Marino
Source: https://docs.coverbase.com/user-guides/supplier-countries/sm
What Coverbase asks a supplier in San Marino for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in San Marino sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for San Marino. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c San Marino validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Senegal
Source: https://docs.coverbase.com/user-guides/supplier-countries/sn
What Coverbase asks a supplier in Senegal for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Senegal sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Senegal. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Senegal validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# El Salvador
Source: https://docs.coverbase.com/user-guides/supplier-countries/sv
What Coverbase asks a supplier in El Salvador for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in El Salvador sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for El Salvador. It is 28 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c El Salvador validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Thailand
Source: https://docs.coverbase.com/user-guides/supplier-countries/th
What Coverbase asks a supplier in Thailand for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Thailand sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Suggested | 3 characters, digits only | 3 digits. |
| Branch number | Suggested | 4 characters, digits only | |
| Account number | Required | 10 to 15 characters, digits only | Usually 10 digits. |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
Thailand does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID | Required | 13 characters, digits only, Thai TIN check digit | 13 digits. |
## Where these rules come from
Bank of Thailand ICAS bank codes; Revenue Department 13-digit TIN. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Tunisia
Source: https://docs.coverbase.com/user-guides/supplier-countries/tn
What Coverbase asks a supplier in Tunisia for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Tunisia sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Tunisia. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Tunisia validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Türkiye
Source: https://docs.coverbase.com/user-guides/supplier-countries/tr
What Coverbase asks a supplier in Türkiye for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Türkiye sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Optional | no length limit, digits only | |
| Account number | Required | up to 20 characters, letters and digits | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Türkiye. It is 26 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Vergi Kimlik Numarası | Required | 10 characters, digits only, VKN checksum | 10 digits. |
## Where these rules come from
Oracle Fusion Cash Management 26c TR validations; GİB VKN checksum.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Ukraine
Source: https://docs.coverbase.com/user-guides/supplier-countries/ua
What Coverbase asks a supplier in Ukraine for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Ukraine sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Ukraine. It is 29 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Ukraine validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# United States
Source: https://docs.coverbase.com/user-guides/supplier-countries/us
What Coverbase asks a supplier in the United States for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in the United States sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Routing Transit Number | Required | 9 characters, digits only, ABA routing checksum | 9 digits, for example, 076401251. |
| Account number | Required | up to 17 characters | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Required | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for the United States. It is up to 34 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| EIN | Required | 9 characters, digits only | 9 digits, for example, 12-3456789. |
After a registration is saved, Coverbase checks it against the IRS TIN matching service in the background. That check never blocks the supplier: it annotates the record once it completes, and a reviewer can retry it.
## Country rules
* Postal codes are checked against the national format. A postal code that does not match produces a warning, not a rejection.
## Where these rules come from
Oracle Fusion Cash Management 26c US validations; IRS EIN prefix list.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# British Virgin Islands
Source: https://docs.coverbase.com/user-guides/supplier-countries/vg
What Coverbase asks a supplier in British Virgin Islands for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in British Virgin Islands sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for British Virgin Islands. It is 24 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c British Virgin Islands validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Kosovo
Source: https://docs.coverbase.com/user-guides/supplier-countries/xk
What Coverbase asks a supplier in Kosovo for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Kosovo sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is optional for Kosovo. It is 20 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Kosovo validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Mayotte
Source: https://docs.coverbase.com/user-guides/supplier-countries/yt
What Coverbase asks a supplier in Mayotte for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in Mayotte sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Optional | up to 60 characters | |
| Bank code | Optional | no length limit | |
| Branch code | Optional | no length limit | |
| Account number | Required | no length limit | |
| Check digit | Optional | no length limit | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
An IBAN is required for Mayotte. It is 27 characters and is checked against the ISO 7064 MOD-97 algorithm, which catches a mistyped or transposed digit before the details reach your finance system.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Tax ID / VAT number | Suggested | up to 32 characters, letters and digits | The registration number the tax authority issued. |
## Where these rules come from
Oracle Fusion Cash Management 26c Mayotte validations, read from the published country validation pages.
The rules on this page are confirmed against a primary source, so they are enforced strictly.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# South Africa
Source: https://docs.coverbase.com/user-guides/supplier-countries/za
What Coverbase asks a supplier in South Africa for, and which of those rules block a submission.
[User guides](/user-guides/overview) / [Supplier countries](/user-guides/supplier-countries/overview)
A supplier whose bank account is held in South Africa sees the fields below. The country is chosen on the form, and changing it changes the fields, so a supplier is never asked for a detail their country does not use.
<Note>
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
</Note>
## Bank details
| Field | Requirement | Format | Notes |
| - | - | - | - |
| Bank name | Required | up to 60 characters | |
| Bank code | Optional | no length limit, digits only | |
| Branch code | Required | 6 characters, digits only | 6 digits, for example, 250655. |
| Account number | Required | 7 to 11 characters, digits only | |
| Check digit | Optional | no length limit, digits only | Optional. Only if your bank statement shows a separate check digit; leave blank if it does not. |
| SWIFT/BIC | Optional | 8 to 11 characters, letters and digits | 8 or 11 characters, for example, BOFAUS3N. Needed for a payment by wire. |
| Account type | Optional | no length limit, one of: checking, savings | Checking unless the bank issued the account as a savings account. |
### IBAN
South Africa does not use IBANs. Accounts are identified by the fields above.
## Tax and company registrations
| Registration | Requirement | Format | Notes |
| - | - | - | - |
| Income tax reference number | Required | 10 characters, digits only, South African tax reference Luhn check | 10 digits. |
| CIPC registration number | Suggested | 12 to 14 characters | for example, 2011/123456/07. |
## Where these rules come from
SARB 6-digit universal branch codes; SARS 10-digit tax reference. VERIFY: no Oracle-specific rule supplied; encoded from public payments documentation. Tighten against real supplier samples during UAT.
Some rules on this page could not be confirmed against a primary source. Those are applied as warnings rather than rejections.
Configuration version `2026.10.1`. Your organization can override any of these rules for its own suppliers.
## Related
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
Every country Coverbase validates, side by side.
</Card>
<Card title="Supplier information guide" icon="building-columns" href="/user-guides/supplier-information">
How these details are collected, reviewed, and handed to your finance system.
</Card>
</CardGroup>
# Supplier information guide
Source: https://docs.coverbase.com/user-guides/supplier-information
How supplier bank details, addresses, tax registrations and diversity records are collected, checked against the rules for the supplier's country, reviewed, and handed to your finance system.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For what each country asks for, field by field, see [Supplier countries](/user-guides/supplier-countries/overview).
</Info>
Onboarding a supplier eventually comes down to a handful of facts you have to get exactly right: where to send the money, where the supplier is, what it is registered as for tax, and whether it qualifies under any diversity program you run. Get a digit wrong in a bank account and the payment fails or, worse, lands somewhere else. Ask for the wrong fields and the supplier gives up halfway through the form.
This part of Coverbase is built around one idea: the country decides the questions. A supplier banking in the United Kingdom is asked for a sort code and an eight digit account number. A supplier banking in Japan is asked for a bank code, a branch code and a deposit type. Nobody is asked for a field their country does not use, and nothing is accepted that the country's own format rules reject.
<Note>
This is a gated feature. If you do not see a **Know-Your-Vendor** tab on your vendors, it has not been switched on for your organization yet. Ask your Coverbase contact.
</Note>
## The short version
<Steps>
<Step title="You ask">
Add a bank details, site, tax registration or diversity question to a questionnaire, and send it as you would any other. There is no separate portal for a supplier to learn.
</Step>
<Step title="The supplier answers">
They pick their country, and the form changes to that country's fields. Each field is checked as they type, so a mistyped check digit is caught while they are still looking at it.
</Step>
<Step title="Coverbase checks it">
On submission, everything is validated again on the server. Errors block the submission and say why. Warnings are recorded and let it through.
</Step>
<Step title="A reviewer decides (for bank changes)">
A new or changed bank account waits in a queue. The supplier's live account is untouched until someone approves the change.
</Step>
<Step title="Your finance system hears about it">
Approval fires a webhook. Rejection fires none, because from your finance system's point of view the change never happened. The change feed your integration polls records both, as `approved` and `rejected` events, so filter on the action before you apply anything.
</Step>
</Steps>
## Where this lives
Three places, depending on who you are.
<CardGroup>
<Card title="On the vendor" icon="building">
A **Know-Your-Vendor** tab on every vendor. **Onboarding** holds the questionnaire sent to the vendor and its verification checks; **Records on file** holds bank accounts, sites, tax registrations, diversity records, legal entity assignments, pending changes, and the full change history.
</Card>
<Card title="In a questionnaire" icon="clipboard-list">
Four question types you can drop into any Know-Your-Vendor questionnaire. This is how suppliers fill things in.
</Card>
<Card title="In configuration" icon="sliders">
**Configuration → Know Your Vendor Settings** for the policy, and **Configuration → Legal entities** for the entities suppliers get assigned to.
</Card>
</CardGroup>
<Frame>
<img alt="The Records on file section of a vendor's Know-Your-Vendor tab, showing masked bank accounts with validation badges, sites, tax registrations and the change history." />
</Frame>
## Asking a supplier: the four question types
Supplier information is collected through the questionnaire engine rather than through a separate flow. That means assignment, reminders, progress tracking, autofill and review all work as they already do, and a supplier who has filled in one Coverbase questionnaire knows how to fill in this one.
When you author a questionnaire on the **Know-Your-Vendor** tab of **Configuration → Questionnaires**, four extra response types appear alongside the usual text and select types:
| Question type | What the supplier fills in |
| - | - |
| **Bank Account** | Country, then that country's bank fields, plus IBAN and SWIFT where they apply |
| **Site / Address** | An address in your finance system's structure (building number, street name, city, and the postal code and state where the country uses them), and the email addresses purchase orders and remittance advice go to |
| **Tax Registration** | The tax and company identifiers that country uses, such as a VAT number or a company number, or a declared exemption in place of one |
| **Diversity Record** | A business classification and, for minority owned, its subclassification; the certifying agency, certificate number, start and expiration dates, the certificate itself, and notes |
They do not appear on assessments or RFPs, because there is no supplier profile behind those to write into.
<Frame>
<img alt="A bank account details question in a questionnaire, showing the country selector and the United Kingdom fields: sort code, account number and IBAN." />
</Frame>
<Frame>
<img alt="A tax registration question showing the country selector, a registration type selector, and the identifier field." />
</Frame>
### What the answer stores
This matters if you export questionnaire responses.
The answer to one of these questions is a **reference, not a payload**. When the supplier submits, the real values go into their own table, encrypted. What lands in the questionnaire response is a row id plus a masked summary: the last four digits, the country, and the validation outcome. Every reader of questionnaire responses, including the CSV export, the follow up spreadsheet round trip and autofill, therefore sees the summary and never the identifier.
<Warning>
These answers cannot be edited through the follow up spreadsheet. A spreadsheet is a text file that anyone in the chain can edit, and accepting one would let a pasted row point an answer at a record it should not reference. The spreadsheet skips these questions and says so.
</Warning>
### Offering a live bank connection
A bank details question has one setting: **Offer a live bank connection**. It is off by default.
Turn it on and the supplier gets the option to link their bank directly instead of typing account details. Leave it off and they only see the country form, and none of the connection logic runs. It is a per question choice rather than an organization wide one, because the ask is heavier than typing and you may want it on your main onboarding questionnaire but not on a quick refresh.
<Frame>
<img alt="A bank account details question offering a live bank connection above the manual country fields." />
</Frame>
### Picking a known bank
Some countries ask for details the supplier has no way to look up. A Colombian form wants the bank's own taxpayer ID, which appears on a bank statement but not on anything a supplier keeps to hand.
Where Coverbase holds a bank list for the country, the supplier picks their bank from a searchable list instead of typing its name, and the fields the list knows are filled in for them. Picking a Colombian bank fills in its code and its taxpayer ID.
A bank the list has never seen is typed as free text. Nothing is filled in, because there is nothing to fill it in from, and the supplier is asked for a recent bank statement showing the account belongs to them. Colombia is the only country that asks for that statement today.
## What a supplier is not asked for
Three values reach your finance system without a supplier ever seeing them, because a supplier has no way to know the right answer and a wrong guess is worse than no answer.
| Value | Where it comes from |
| - | - |
| Tax region | The address. It is the country code, or the country and state for the four countries that levy tax below national level: the United States, Canada, India and Brazil. |
| Payment method | Whether the account is cross border. An account held in a country none of the supplier's assigned legal entities pay from goes out by wire; an account in one of their countries is domestic. A supplier with no legal entity assignment gets no payment method until one is assigned. |
| Bank code and bank taxpayer ID, where a bank list exists | The bank the supplier picked, as described above. |
An import from your own finance system can carry its own tax region, and that value wins. Nothing else overwrites it.
## What happens when a supplier submits
### Normalizing first
Before anything is judged, values are cleaned up in the way that country expects. Spaces come out of an IBAN. A United Kingdom sort code shorter than six digits is padded with leading zeros rather than rejected, because people do type five digit sort codes and the leading zero is implied.
### Then errors and warnings, which are not the same thing
<CardGroup>
<Card title="An error blocks" icon="circle-xmark">
The field is required and empty, the length is wrong, the pattern does not match, or a checksum failed. The submission is refused and the message names the field and the reason.
</Card>
<Card title="A warning informs" icon="triangle-exclamation">
Something looks unusual but we are not certain enough about that country's rules to reject a real supplier over it. The record saves, the warning is recorded against it, and a reviewer sees it.
</Card>
</CardGroup>
Each country page carries a **rule confidence** rating, and it is a statement about our evidence, not about the supplier. Where a rule is confirmed against a primary source such as a tax authority or a central bank, it is enforced strictly. Where it comes from secondary documentation, it warns instead. Promoting a rule without evidence would mean rejecting suppliers who are doing nothing wrong, which is the failure this is built to avoid.
### Checksums
A checksum is a self checking digit built into an identifier: an IBAN, a US routing number, a Spanish NIF, a Mexican CLABE. It catches the most common human errors, a mistyped digit and a transposed pair, before the details ever reach your finance system. Coverbase implements the published algorithm for each identifier that has one, and only those. Where an identifier's check digit rule is not publicly documented, the format is checked and the checksum is not invented.
The per country pages say exactly which checks apply. See [Supplier countries](/user-guides/supplier-countries/overview).
### Registry confirmation, afterwards
Where a public register exists, a tax or company registration is looked up in the background after it is saved. Companies House and HMRC for the United Kingdom, the VIES service for European VAT numbers, and so on.
This is never part of validation. It runs afterwards, it annotates the record with what the register said, and a reviewer can retry it. A register being slow or down has no effect on a supplier's ability to submit their details, which is why it sits outside the validation path.
### Rules that read more than one field
Most rules judge a field on its own. These read a second value, so they can only run on submission rather than as the supplier types.
| Rule | What it does |
| - | - |
| Cross border payment | An account in a country none of your assigned legal entities pay from needs a SWIFT/BIC, because the payment goes out by wire. The supplier is told rather than blocked, and the derived payment method is stored on the account. |
| Currency held for local suppliers only | BRL is refused on an account whose supplier is not in Brazil. The test is the supplier's own country, not the bank's, so a Brazilian supplier banking abroad still qualifies. |
| The IBAN and the fields inside it | Where a supplier gives both an IBAN and the bank, branch or account codes separately, those codes must appear inside the IBAN. A mismatch is a warning, because the two came from different documents and either could be the stale one. |
| A name in the local script | Twelve countries write in a script a romanized name cannot stand in for, among them Japan, China, Korea and Greece. The form asks for the legal name in that script alongside the romanized one, and warns if what is typed is not in it. |
| A registration without its certificate | Thirteen Latin American countries ship the certificate that proves a registration. This warns rather than blocks: a supplier who has the number but not the PDF to hand can still finish. |
### Question settings
Each of these question types has settings in the questionnaire builder, under the response type:
| Setting | Question | What it does |
| - | - | - |
| **Multiple Entries** | Site, tax registration, diversity | Lets the supplier add more than one record, or narrows the question to one. |
| **Address Type** | Site | **Primary address** makes the answer the supplier's main address. **Remit-to address** makes it the address payments are remitted to. Either one must be a complete address before it saves. **Any location** also accepts a country on its own. |
| **Exemption Document** | Tax registration | **Suggested** asks for the document behind a tax exemption but lets the supplier submit without it. **Required** blocks the submission until it is attached. |
### Answers that build on earlier ones
The form reuses what the supplier already entered, so they type an address once:
* **Countries follow the main address.** Once the primary address is saved, every later address and the bank details open on its country. The supplier can pick another country, and from then on the form leaves their choice alone.
* **Same as main address.** A remit-to address question offers a **Same as main address** box. Ticking it copies the main address and keeps the two in step until the supplier saves. A list beside it copies any other address from the form, which the supplier can then edit.
* **The bank is paid against the remit-to address.** A bank details question shows a **Remit-to address** list, set to the remit-to answer. Your finance system receives the link with the account.
## Addresses hold more than an address
An address carries the details your finance system needs to pay against it, not only the lines and the postal code.
* **Your finance system's structure.** Line 1 is the building number (up to 16 characters) and line 2 the street name (up to 70). The city (up to 35) is required, the postal code (up to 16) is required everywhere except countries with no postal codes, and the state or province is required in the United States and Canada. The form shows a running character count and says which field is missing before the supplier saves. An address that is only a country is still accepted where the question allows any location.
* **Purpose.** An address is a **Primary** or a **Remittance** address. An address is a registration address by carrying a tax registration rather than by being marked as one, so a single address can be both where the supplier is registered and where remittance advice goes.
* **Email lists.** Two lists per address: where purchase orders go, and where remittance advice goes. A malformed address is refused. A missing one is a warning, on the primary address and on any remittance address, and is never asked for in China.
* **Tax registrations.** A tax registration can attach to one address rather than to the supplier as a whole, which is how a supplier registered in more than one region records each registration against the site it belongs to.
## Registrations a supplier is exempt from
A supplier who is exempt from a registration has no number to give. Ticking the box that says the supplier is exempt from that registration replaces the identifier with a **Reason for exemption**, which is required. The two are alternatives: a submission carrying both is refused.
An exempt supplier is also asked for a **Supporting document**, such as the legal provision or the certificate their tax authority issued. Whether it is suggested or required is the question's **Exemption Document** setting.
## Diversity classifications
A diversity record takes the same shape as a business classification in Oracle Fusion:
| Field | Notes |
| - | - |
| **Classification** | HUBZone, India medium business, India micro business, India small business, Minority owned, Service-disabled veteran owned, Small business, Veteran owned, or Women owned. |
| **Subclassification** | Shown for **Minority owned** only: African American, American Indian, Asian, or Hispanic. |
| **Certifying agency** | The agencies that certify the chosen classification, or **Other** with the agency's name typed in. |
| **Certificate number**, **Start date**, **Expiration date** | The **Status** reads Current, Expired or Not yet valid from the dates. |
| **Attachment**, **Notes** | The certificate itself, and anything a reviewer should know. |
**None of the classifications are applicable** is a recorded answer, so the supplier is not asked again.
## Asking an existing supplier to update their details
Use an update request when a supplier you already hold needs to change something specific: a new bank account, an account in a new currency, a moved address, a new PO email address, or their contacts. It works the same for a supplier you onboarded in Coverbase and one whose details were loaded from your finance system.
1. Open the vendor and go to the **Know Your Vendor** tab.
2. In **Update Requests**, click **Request update**.
3. Enter the supplier contact who should receive it.
4. Tick each section the supplier should update. For each one, choose what you need and write a note:
* **Bank accounts**: **Change an account**, **Add an account** (for example a new currency), or **Confirm details**.
* **Addresses**: **Moved location**, **Add an address**, or **Confirm details**.
* **PO email address**, **Contacts**, **Tax registrations** and **Diversity**.
* **Legal entities**: pick up to five of your own entities to add. These are requested in your name when you send. If **Legal entity assignments need approval** is on, approve them on the **Legal entities** card.
5. Click **Send request**.
<Frame>
<img alt="The Request Supplier Update dialog with bank accounts set to Change an account and two legal entity fields open." />
</Frame>
The supplier receives an email that opens the **Profile** page of their supplier portal. Your note appears on the section it belongs to. Only the sections you ticked can be edited; the company name and everything else stay read only.
<Note>
The **Profile** section of the supplier portal must be switched on in **Configuration → Portal → Centralized Portal**. Coverbase refuses to send a request while it is off, because the email's link would have nowhere to land.
</Note>
What the supplier can do on each section:
* **Change an account or address.** They pick which one they are replacing, then enter the new details. A bank change waits in the review queue against the account it replaces, and your finance system keeps paying the old account until you approve it.
* **Add** a new record.
* **Confirm details** with **This is still correct**, when nothing has changed.
* **Contacts.** They mark people to remove and add new ones. Nothing changes on the vendor until you click **Apply to contacts**.
When they finish, they click **Send update**. The sections close for editing and you get a notification. The request then shows **Returned** on the **Update Requests** card, with what they confirmed, any contact changes waiting for you, and how many bank changes from it are in the review queue. Click **Mark reviewed** when you are done, or **Withdraw request** to close one the supplier has not sent back.
## Review: the part that stops fraud
Invoice redirection fraud, where an attacker persuades someone to change a supplier's bank details, is one of the most common and most expensive attacks in accounts payable. The review queue exists for it.
By default, **a bank change never touches the live account**. It goes into a queue and waits. The supplier sees that their submission is recorded and awaiting review. The account your finance system knows about is unchanged, and no webhook fires. When a reviewer approves, the change lands and the webhook goes out. When a reviewer rejects, nothing is restored, because nothing had been replaced.
The queue is the **Vendor changes** page. Open it from the **Vendor changes** button at the top of the vendor page, which shows a count when something is waiting. The same page also lists subprocessor suggestions waiting for a decision.
<Frame>
<img alt="The Vendor changes page listing pending bank account changes awaiting review, with approve and reject actions." />
</Frame>
Two things enforce the control:
* **Submitting and approving are different permissions.** Someone who can enter a change cannot necessarily approve it. That includes your own staff entering details on a supplier's behalf from the vendor tab.
* **The change history is append only.** Every supplier visible change writes an event, and nothing updates or deletes one. That history is the same source the API delta feed and the webhook payloads read from, so what a reviewer sees and what your finance system received cannot drift apart.
## Who can see and do what
Two permission resources, each split three ways, so a reviewer does not have to also be an editor.
| Permission | What it allows |
| - | - |
| Supplier banking: read | Reveal a full bank identifier. Without it, everyone sees the last four digits only. |
| Supplier banking: update | Enter or edit bank details on a supplier's behalf. Does not approve anything. |
| Supplier banking: approve | Decide a queued bank change. |
| Supplier profile: read | Reveal a full tax identifier. |
| Supplier profile: update | Edit sites, tax registrations, diversity records and legal entity assignments. Send, withdraw and close update requests. |
| Supplier profile: approve | Decide a queued legal entity assignment. Apply contact changes a supplier proposed. |
<Frame>
<img alt="The staff dialog for adding a supplier address, showing the country-driven address fields and a notice that the record is being entered on the supplier's behalf." />
</Frame>
<Note>
These are organization wide permissions rather than per vendor ones. There is no assignment model on a bank account, so "owns the vendor" is not a route to approving its bank changes.
</Note>
Every reveal of a full identifier is recorded. Everywhere else, and that means change events, webhook payloads, delivery logs and API responses that are not explicitly a reveal, only the last four digits exist.
## Configuring it for your organization
The **Know Your Vendor** section of **Configuration → Know Your Vendor Settings** holds the policy. Everything on it is per organization.
<Frame>
<img alt="The Know Your Vendor section of the configuration page, showing review and approval settings, collection options, limits and update request defaults." />
</Frame>
<AccordionGroup>
<Accordion title="Review and approval" icon="user-check">
**Bank changes need a reviewer** is on by default and is the fraud control described above. **Legal entity assignments need approval** is off by default, because an assignment is an administrative fact rather than a payment instruction. **Notify these people** decides who hears about a queued change; leave it empty and the vendor's relationship owners are told instead, so a half configured organization still reaches a human.
</Accordion>
<Accordion title="What suppliers are asked for" icon="list-check">
**Collect IBAN** and **Collect country specific extras** apply across every country. Turning an extra off skips fields such as a building society roll number or a branch code that only some countries use. **Diversity certifications** narrows certificate collection to named countries; leave it empty to collect everywhere.
A diversity record carries an **inclusion category** and a **business size**. The category list follows the certification programs the United States and Canada run, so a supplier picks the one they hold a certificate for rather than describing themselves. Business size is Large, Medium or Small, and is taken from the certificate rather than worked out from headcount, because the size a supplier is certified under is the one the program counts.
</Accordion>
<Accordion title="Limits" icon="gauge">
How many bank accounts and sites one supplier may hold, and how many profile writes a supplier portal may make per hour. The rate limit is low. Profile edits are rare, so a burst is far more likely to be an attack than a real supplier.
</Accordion>
<Accordion title="Update requests" icon="rotate">
When you ask an existing supplier to refresh their profile, these are the defaults: which sections the request covers, and how long the supplier's link stays usable. The person sending a request can narrow the sections for that request.
</Accordion>
</AccordionGroup>
### Legal entities
**Configuration → Legal entities** is the list of your own contracting entities that suppliers get assigned to. The **entity code** is what your finance system matches on, so it has to be exactly what that system expects. Entities can be imported from CSV, which upserts on the entity code and reports the outcome per row.
Deactivating an entity blocks new assignments and leaves existing ones alone.
One assignment request covers up to five entities. A request that quotes a purchase requisition raised more than thirty days ago needs a justification before it is accepted; a request quoting no requisition cannot be stale and is not asked for one.
### Country rules
The 109 countries ship with rules already configured, and those are documented per country in [Supplier countries](/user-guides/supplier-countries/overview). Coverbase can override any country's rules for your organization's suppliers, which is how a late correction from your finance team becomes a configuration change rather than a release. Ask your Coverbase contact.
## Getting it into your finance system
Two ways, and most integrations use both.
<CardGroup>
<Card title="Webhooks" icon="broadcast-tower">
Fired when a record is created, changed or approved, and when a legal entity assignment is rejected. A rejected bank change fires nothing. Payloads carry masked identifiers and an idempotency key drawn from the change event, so a redelivery cannot double apply.
</Card>
<Card title="The changes feed" icon="arrows-rotate">
A polling endpoint that returns everything that changed since a cursor you hold. Use it to reconcile after an outage, or as your primary path if you would rather poll than receive.
</Card>
</CardGroup>
A bank change's webhook fires on approval, not on submission. If you are testing the integration and a submitted change is not showing up, that is almost always why: check the review queue.
## When something goes wrong
| What you see | What it usually means |
| - | - |
| The supplier says a valid account number is rejected | Check the country on the form. The fields follow the country of the bank account, not the country of the supplier. |
| A check digit error the supplier insists is wrong | Have them re-read the identifier from the bank's own document rather than from an invoice template. Transposed digits are the most common cause. |
| A warning on an otherwise fine record | The rule is a suggested one for that country. The record saved. The country page says which rules are suggested and why. |
| A supplier's new bank details are not in the finance system | The change is waiting in the review queue. Nothing is sent until it is approved. |
| Nothing was sent after approval | Check webhook delivery, then reconcile with the changes feed. |
| "This supplier already has N bank accounts" | The organization's bank account limit. Raise it in configuration, or retire an account that is no longer used. |
| **Registry check pending** or **Registry unavailable** on a tax registration | The background check runs every 15 minutes. **Registry unavailable** means the register could not be reached; it retries on its own, and **Retry verification** runs it again by hand. It never blocks anything. |
| A warning asking for a SWIFT/BIC on a domestic-looking account | The account's country is not one your assigned legal entities pay from, so the payment is treated as a wire. Check the legal entities assigned to that supplier. |
| A Colombian supplier is asked for a bank statement | They typed a bank name the list does not hold. Have them check the spelling against their statement; a bank on the list fills its own details in and asks for nothing. |
| "BRL is held for suppliers in BR only" | BRL is held for suppliers in Brazil. The test is the supplier's own country, not the bank's. |
| A warning that the IBAN and the bank codes disagree | The two were taken from different documents. Have the supplier confirm which is current, usually the IBAN. |
## Where to next
<CardGroup>
<Card title="Supplier countries" icon="globe" href="/user-guides/supplier-countries/overview">
All 109 countries, with the exact fields, formats, checksums and registers for each one.
</Card>
<Card title="Requesting a vendor" icon="cart-shopping" href="/user-guides/requesting-a-vendor">
What happens before any of this: how a supplier gets into Coverbase in the first place.
</Card>
<Card title="Supplier Profile API" icon="code" href="/api-reference/supplier-profile">
Read and write the same bank accounts, sites and tax registrations from your own systems.
</Card>
</CardGroup>
# The supplier portal, for suppliers
Source: https://docs.coverbase.com/user-guides/supplier-portal-for-suppliers
What a supplier sees at their customer's portal: signing in, everything open with that customer, keeping their own details current, and bringing colleagues in.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. Share it with your suppliers. For the settings behind it, see [Centralized supplier portal](/user-guides/centralized-supplier-portal).
</Info>
Your customer has given you one page for everything they have open with you. This is what is on it.
## Getting in
You do not have a password. Two ways in:
<Steps>
<Step title="From an email they sent you">
Open the link. It signs you in and lands you on the portal.
</Step>
<Step title="From the portal itself">
Go to the address your customer gave you and enter your work email. A sign-in link arrives in your inbox.
</Step>
</Steps>
The reply never says whether your address is on a supplier list, so you cannot tell from it whether you were expected. If no link arrives, ask whoever invited you.
If you work with several Coverbase customers, one address covers all of them, and the first screen asks which one you want. After that, the account menu at the bottom of the left rail lists them under **Your customers**, with how many requests each has open, so you can move between them without going back to that screen.
If your company uses Coverbase for its own supplier reviews, the same menu has a **Coverbase dashboard** section that opens your workspace, and so does the menu under your address at the top right of the first screen. From your workspace, the switcher at the top left of the navigation lists your customers' portals under **Supplier portals**.
<Note>
Opening a link addressed to a colleague signs you in as them. On a shared machine, sign out from the account menu at the bottom of the left rail when you are done.
</Note>
## What is on the page
<CardGroup>
<Card title="Home" icon="house">
What is due soonest, and what is waiting on your customer rather than on you.
</Card>
<Card title="Requests" icon="file-lines">
Everything open, grouped by kind. Each row shows its reference, what it is, and when it is due.
</Card>
<Card title="Messages" icon="comments">
One thread per request, shared with your customer's team. A dot marks a thread with something you have not read.
</Card>
<Card title="Documents" icon="folder">
What you have uploaded and what you have sent. Download anything back. Only a file you uploaded and have not submitted can be removed.
</Card>
<Card title="Team" icon="users">
Who at your company can open this portal, and who owns each piece of work.
</Card>
<Card title="Profile" icon="id-card">
What this customer holds about you, and what you may change. Only if they have switched it on.
</Card>
</CardGroup>
An **Obligations** section appears if your customer publishes findings to you.
## Your team
The first person to sign in becomes the owner. An owner can:
* Invite colleagues, as owner or contributor
* Assign any request to a colleague, who is emailed about it
* Approve or decline a colleague who asks for access
* Remove someone
A contributor can do the work but cannot change who is on the team.
If a colleague reaches the portal before being invited and their email shares your domain, they can ask. The owner decides, and they are emailed either way.
<Note>
Some requests are marked confidential and are visible only to the people named on them. They do not appear in your list until somebody names you.
</Note>
## Keeping your details current
If your customer has switched the **Profile** section on, it shows what they hold about you: bank accounts, addresses, tax registrations, diversity records and the legal entities you trade with.
Bank and tax identifiers are shown as the last four digits only. That is deliberate. You already have the full number, and if you are changing it you are typing a new one.
Each section is in one of three states:
| What you see | What it means |
| - | - |
| A lock and **Read-only** | Ask your customer if something here is wrong. |
| A button such as **Add a bank account** or **Edit invoice emails** | Open. You can make a change whenever you like. |
| A highlighted note starting with your customer's name and **asked:** | Your customer has asked you about this section and says what they want, such as **Review what we hold**. |
### When your customer asks you to update something
Your customer can send you a request to update specific details. You get an email with a link to your **Profile** page, and the request shows at the top of the page with the sections it covers and the date it is due.
<Frame>
<img alt="The supplier portal profile page with an update request banner and a note from the customer on the bank accounts section." />
</Frame>
* **Change a bank account** or **Change an address**: choose the one you are replacing, then enter the new details.
* **This is still correct**: tells your customer a section needs no change.
* **Contacts**: mark people to remove and add new ones. Your customer reviews these before they take effect.
* Your company name is shown with a lock. Only your customer can change it.
When you have finished, click **Send update to** your customer. The sections they asked about close for editing once you send.
### Proposing a change
Open the section, fill the form, submit. The form asks for the fields your country uses, and checks them as you type.
**A bank account change does not take effect until your customer approves it**, and they keep paying your current account until they do. Other updates, such as a new address or tax registration, take effect as soon as you submit them. The **Changes** tab lists what is waiting on your customer, what they decided, and the reason if they declined it.
<Warning>
Coverbase will never email you asking you to confirm bank details by replying. A change to where you are paid is made here, on the portal, and it is reviewed by a person at your customer before anything moves.
</Warning>
## Starting something yourself
If your customer offers it, **Submissions** lets you start a request rather than wait to be asked: reporting a security incident, sending a renewed insurance certificate, notifying a change of control. What you start gets a reference number and lands in their queue like anything else.
## Answering a long questionnaire
A questionnaire with sections shows each one as a card with an answered count. When you finish a section, it folds and the next unfinished section opens, so you can keep going without hunting for it. **Expand all sections** at the top opens every section at once, and **Collapse all sections** folds them again.
Addresses you enter carry forward. Once your primary address is saved, later addresses and your bank details open on the same country, and a remit-to address can be set to **Same as main address** instead of typed again.
## Drafting answers with AI
On a questionnaire request, **Draft answers with AI** fills in answers for you from the files you upload to the request and, unless you switch it off in the dialog, public information about your company.
* Add at least one file first. Public information on its own is not enough to start.
* Only unanswered questions are drafted. Anything you have typed is never overwritten.
* Each drafted answer is marked **AI draft** with the files and pages it came from. Read it before you submit.
* A question your files do not cover stays blank and is marked **Requires an answer**. **Next** steps through them.
* You can keep working or leave the page while it runs. If you are signed in, you get an email when it finishes.
* If drafting stops, the card says why and offers **Try again**.
## Uploading documents
Documents, spreadsheets, presentations, images, archives and emails, up to 100 MB each. Anything else is turned away with the list of what is accepted. A file you uploaded but have not sent can be removed; one already submitted against a request is your customer's record and stays.
## When something looks wrong
* **A link lands on "this request is no longer available"**: the link was mistyped, or the request has been withdrawn. Ask for a new one.
* **The portal says your customer has closed this portal**: nobody removed you. Links they already sent still work, and asking for access will not bring it back.
* **You cannot see a request a colleague mentions**: it may be confidential and limited to named people. Ask your owner.
# Financial health and security intelligence guide
Source: https://docs.coverbase.com/user-guides/vendor-fact-sheet
How to read the Financial Health Score and External Security Intelligence cards in a vendor's Vendor Intelligence section, what each number claims, and what to do about what you find.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the two scored cards in a vendor's Vendor Intelligence section. For the product-level explanation of where the data comes from, see [Financial Health Score](/products/financial-health-score) and [Security Intelligence](/products/security-intelligence); for the corporate identity both are computed against, [Vendor Intelligence](/products/vendor-intelligence).
</Info>
<Note>
These are optional features. If you do not see the cards described here, ask your Coverbase representative to turn them on.
</Note>
Two cards in Vendor Intelligence carry a score rather than a description: **Coverbase Financial Health Score** and **External Security Intelligence**. Both are assembled without contacting the vendor: one from regulatory filings and registries, the other from the vendor's own public infrastructure.
This guide is about reading them correctly. Both cards can be checked against their sources, and the most common mistake is treating a number as more certain than the card says it is.
## Start with the qualifier, not the number
Every score on these cards comes with a qualifier that tells you how much to trust it. Read that first.
<CardGroup>
<Card title="Financial health: the confidence tier" icon="layer-group">
**A** means filed financial statements. **B** means estimates. **C** means no financials at all, so the score was inferred from funding, headcount, and corporate standing. The tier is derived from what resolved, never declared.
</Card>
<Card title="Security: what was measured" icon="circle-question">
Factors that could not be measured are excluded from the rating rather than scored as failures. A card showing eight of eleven factors is rating what it could see, and says so.
</Card>
</CardGroup>
<Warning>
Scores are held to a common scale across tiers, so ranking a portfolio on the number is reasonable. The tier still says how much evidence stands behind each one: a Tier C 72 and a Tier A 72 are different claims about different evidence. Before you act on a surprising score, check its tier.
</Warning>
## Working the financial health card
<Steps>
<Step title="Check the tier and the trend together">
A Tier A score with 12-month movement is the strongest signal on the page. A Tier C score is a starting point for questions, not a conclusion. If a vendor you know to be public is sitting at Tier C, that usually means no filings resolved. Check the Corporate Registration card to see whether SEC EDGAR is listed as unavailable.
</Step>
<Step title="Open the rationale on the weakest pillar">
The pillar breakdown shows five scores. Open the rationale on the lowest one and you will see the individual inputs, each with its measured value, its own score, and the weight it carried.
Watch for inputs labeled as undeterminable rather than measured. A pillar dragged down by a value nobody could establish is a different finding from one dragged down by a bad ratio.
</Step>
<Step title="Check whether the inputs were peer-ranked">
A ratio only means something against a comparable set: 4x debt/EBITDA reads very differently at a utility than at a software company. Inputs scored against the vendor's own industry cohort are labeled as peer-ranked. Those scored against an absolute curve are not, and deserve more skepticism.
When a cohort is too small to support a percentile, the score falls back to a wider group and the card says so.
</Step>
<Step title="Read the adverse events, including the dismissed ones">
Events are weighted by severity and decay over time. Events awaiting confirmation are labeled **Needs review** and do not move the score until they are confirmed. An event that is about another company can be dismissed from the full **Financial** page with **Revise from notes or evidence**. Dismissed events stay on the record for audit but stop affecting the number.
</Step>
<Step title="Check the as-of dates before you quote a figure">
Filed figures lag. Each input carries the date its value was true, which is not the date of the refresh. Quote the as-of date alongside any figure you pass on.
</Step>
</Steps>
## Working the security posture card
<Steps>
<Step title="Read the grade, then the factor breakdown">
The overall grade is a weighted mean across eleven factors. It is useful for triage and misleading on its own: a B can hide an F in email security under strong scores elsewhere. Scan the factor list for the outliers.
</Step>
<Step title="Open the rationale on any factor that grades poorly">
Each finding names what was observed, where, and what it cost. These are concrete: `p=none` on the DMARC record, `1024-bit` on DKIM selector `selector1`, a session cookie set without `HttpOnly`.
Everything here is a public record you or the vendor can verify independently. That is what makes it usable in a conversation.
</Step>
<Step title="Check how long the finding has been open">
A finding carries the date it was first seen. A weak key that appeared last week is an oversight. One that has stood open for eleven months has probably been seen by the vendor's own team and left in place, which says something about how they run security.
</Step>
<Step title="Compare the rating against the predictive index">
The rating asks how well the vendor is configured. The predictive index asks how likely something is to happen soon, based on known-exploited vulnerabilities, exploitation probability, and ransomware association.
When they diverge, act on the index. A well-configured vendor running one product with an actively exploited CVE needs attention its letter grade will not prompt.
</Step>
<Step title="Turn a finding into a question, not an accusation">
A useful question is specific and verifiable: "your DMARC record is `p=none`, so mail forged from your domain still gets delivered. Is enforcement on the roadmap?"
That is a fact about a published record. The vendor can confirm it quickly, and it turns a generic security review into an answerable question.
</Step>
</Steps>
## What these cards will not tell you
<Warning>
A clean external security profile is **not** evidence of good internal security. Everything on the External Security Intelligence card is visible from outside the perimeter. It says nothing about access control, key management, secure development, incident response, or how the vendor handles your data once it is inside their systems.
</Warning>
The same applies to financial health in a different direction: the score describes the corporate entity Coverbase bound to the vendor. If a vendor is a subsidiary and the filings belong to the parent, the score describes the parent's balance sheet, not the entity on your contract. Check the Corporate Registration card to see which legal entity was matched.
## Opening the full page
Each card summarizes. Behind it sits a full page with the same data and far more of it, reached from **View full analysis** on the card or from the **Security** and **Financial** entries nested under **Vendor Intelligence** in the vendor's left-hand navigation.
<CardGroup>
<Card title="Security posture" icon="shield-halved">
The rating as a headline figure with its grade and band, plotted against the rating bands over time. Every scored factor is grouped and expandable down to the individual findings that cost it points, each with the record it read and how long it has been open.
Then a section per class of evidence: known vulnerabilities ordered by whether attackers are exploiting them rather than by severity alone; the internet-facing attack surface; email authentication; web and transport hardening; credential exposure from third-party breaches; lookalike domains; web reputation; and which sources the scan used or skipped.
</Card>
<Card title="Financial health" icon="chart-line">
The score with its confidence tier and peer standing, plotted against the risk bands over time with tier changes called out.
All five pillars expand to the measured inputs behind them, alongside a chart ranking where the points are going, because a weak pillar carrying 5% of the weight matters far less than a middling one carrying 40%. Below that: the full vitals set grouped as a credit reviewer reads it, the debt maturity schedule, the peer benchmark, the event timeline, and every source with any cap or floor that was applied.
</Card>
</CardGroup>
<Tip>
The full pages have their own URLs, so a specific vendor's security posture or financial health can be linked directly into a ticket or an email.
</Tip>
## Common questions
<AccordionGroup>
<Accordion title="The vendor is public but shows Tier C. Why?" icon="circle-question">
Tier C means no financial statements resolved. Open the Corporate Registration card and look at the sources: if SEC EDGAR is listed as unavailable, no CIK was matched. That usually means the vendor's name on file differs from its registered legal name. Correcting the vendor's name and refreshing Vendor Intelligence normally resolves it.
</Accordion>
<Accordion title="A security factor is missing from the breakdown." icon="circle-minus">
It could not be measured on the last run, so it was excluded from the rating rather than scored as a failure. A probe that timed out is not evidence about the vendor. It will reappear on a later refresh if the vendor's infrastructure answers.
</Accordion>
<Accordion title="The security score moved and nothing changed at the vendor." icon="arrows-up-down">
Two things can cause this. A factor that was previously unmeasurable may now be measurable (or the reverse), which changes what the weighted mean is averaging over. And when your organization first enables the feature, the rating switches from seven factors to eleven with new weights, so expect a one-time shift at that point.
</Accordion>
<Accordion title="Can I dispute a finding?" icon="flag">
Every finding names the record it read, so start by checking it yourself; a DNS record or a response header takes a moment to verify. If the record has changed since the last refresh, click **Refresh all** on the Vendor Intelligence overview and the finding will clear on its own. If a finding or vulnerability is not about this vendor, open the full **Security** page, pick **Revise from notes or evidence** from the actions menu (**...**), and paste why. The change applies to your organization only. See the [security intelligence guide](/user-guides/security-intelligence#revising-the-page).
</Accordion>
<Accordion title="How often do these refresh?" icon="rotate">
Both refresh on the regular Vendor Intelligence cadence, and on any manual refresh you trigger from the vendor. Score history is kept as discrete points (one per day at most), so the trend line reflects separate computations rather than a smoothed curve.
</Accordion>
</AccordionGroup>
## Where else this data shows up
Once enabled, both feed the rest of the platform:
* **Assessments** consult measured posture and registry facts as authoritative evidence, ranked ahead of any web result. A control asking about email authentication gets answered from the vendor's DNS records rather than from a marketing page.
* **Intake and inherent risk** score a new vendor request against its registered identity and measured posture before the web is consulted.
* **MCP** exposes both conversationally: "what's the financial health score for Acme?", "which of my vendors have DMARC set to none?"
* **The API** returns both on the vendor fact-sheet endpoint (the route name predates the Vendor Intelligence label). See the [API reference](/api-reference/vendors#vendor-intelligence-sections).
## Related
<CardGroup>
<Card title="Financial health guide" icon="chart-line" href="/user-guides/financial-health-score">
The full Financial health page, pillar by pillar.
</Card>
<Card title="Security intelligence guide" icon="shield-halved" href="/user-guides/security-intelligence">
The full Security page, including the attributed estate.
</Card>
<Card title="Corporate registrations guide" icon="building-columns" href="/user-guides/corporate-registrations">
The legal entity both scores are computed against.
</Card>
</CardGroup>
# The vendor record
Source: https://docs.coverbase.com/user-guides/vendor-record
How to read the Vendors list and a single vendor's page: the columns, filters and saved views, creating a vendor from the directory, the cards and tabs on the record, services and engagements, subprocessors, statuses, and what archiving does.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the vendor record itself. For getting a vendor in through intake, see [Requesting a new vendor](/user-guides/requesting-a-vendor); for what to do once the record exists, see [Running an assessment](/user-guides/running-an-assessment).
</Info>
A vendor record is the home for everything Coverbase knows about one supplier: who owns the relationship, what you buy from them, the assessments and documents, the contracts, the open findings, and the companies they in turn depend on. Every other module links back to it, so a duplicate or mislinked vendor spreads into assessments, reports and dashboards.
The mistake people make most often is creating a vendor from scratch when the company already exists, either in your own workspace or in the Coverbase directory. The picker shows both before it lets you add something new. Take the match when there is one.
## Where vendors live
Click **Vendors** in the left navigation. The page opens on the vendor list, with a view switcher at the top:
| View | What it lists |
| - | - |
| **Vendors** | One row per vendor. This is the default. |
| **Services** | Every service across every vendor, with its own risk and assessment columns. Shown when your role can read services. |
| **Engagements** | Every engagement, with start and end dates, status, and the services and contracts it links. Shown when your role can read services. |
| **Nth Parties** | The companies your vendors depend on, with a relationship graph beside the table. |
| **Discovered** | Records found by a connected integration, waiting to be approved or dismissed. Only appears when an integration has reported something. |
The rest of this guide is about the **Vendors** view and a single vendor's page. Services, engagements and nth parties get their own sections below.
<Frame>
<img alt="Vendors list with columns, filters and the New Vendor button" />
</Frame>
## Reading the vendor list
### Columns
| Column | What it shows |
| - | - |
| **Vendor Name** | The record name. Click it to open the vendor. |
| **Tags** | The tags on the record. |
| **Date Added** | When the record was created. |
| **Inherent Risk** | The inherent risk level, from the IRQ or set by hand. |
| **Residual Risk** | The residual risk level, when your organization tracks it. |
| **Risk Domains** | Per-domain inherent risk, when risk domains are configured. |
| **Status** | The lifecycle status. See [Statuses and lifecycle](#statuses-and-lifecycle). |
| **Last Assessed**, **Assessment Outcome**, **Assessment Score**, **Next Assessment** | Read from the vendor's assessments. |
| **Services** | The vendor's active services. |
| **Risk Analysts**, **Relationship Owners**, **Watchers** | The people on the record. |
| **# Docs**, **# Assessments**, **# Issues**, **# Open Issues** | Counts across the record. |
Custom fields that apply to vendors appear as extra columns. Use **Display options** to choose which columns are visible and in what order.
### Search, filters and saved views
The search box matches on vendor name. The filter button opens the unified filter builder, where the fields are grouped: **Dates** (Created Date, Next Assessment Date, Last Assessed), **Documents** (Document Types, Document Count, Uploaded Date), **Assessments** (Assessment Count, Status, Outcome, Assignee, Zero Touch, Has Open Issue, and more), **Contracts** (Auto Renewal, Expiration Date, Renewal Date, Notice Due Date, the other contract dates, and Contract Count), plus Tags, Status, Tier, the three people fields, Website, the inherent and residual risk levels and scores, Risk Domains, and **Archived**.
Filters, sort, search and column layout can be saved as a view. **All vendors** is the built-in view. Use **New view** to save the current state, choose **Personal**, **Shared** or **Organization** under **View access**, and switch between views with **Change view**. Views are also where you get a stable link: `/vendors/view/<id>` opens the list with that view applied.
<Tip>
Archived vendors are hidden from the list. To find one, add the **Archived** filter. The vendor's page still opens and shows an **Archived** badge.
</Tip>
### Row and bulk actions
Each row has a menu with **New Assessment** and **Archive**. Select several rows and a floating bar appears with **Vendor actions**: **Tags**, **Assign relationship owner**, **Assign risk analyst**, **Update status**, **Add to case**, **Create assessments**, **Schedule next assessment**, and **Archive**. Organizations with Zero Touch Assessments also get a bulk launch here.
### The Actions menu
The **Actions** menu in the toolbar holds the portfolio-level tools:
| Item | What it does |
| - | - |
| **Export as Excel** | Builds a consolidated vendor workbook. You can apply the current filters and column visibility, and include a services tab and a locations tab. The first column is always the Vendor ID, so the workbook imports back to update the same vendors. |
| **Build portfolio report** | Builds a PDF summary of the vendors matching the current filters. |
| **Import or update vendors** | Creates or updates vendors (and optionally services and locations) from a spreadsheet. Walkthrough: [Admin setup, Step 2](/user-guides/admin-setup#step-2-import-your-vendor-portfolio). |
| **Bulk upload vendor documents** | Uploads a ZIP with one folder per vendor. Folder names must match vendor names exactly. You get a notification when processing finishes. |
| **Merge vendors** | Scans for duplicates and merges them. See [Merging and archiving](#merging-and-archiving). |
| **Export services** | The same workbook export for the services list. |
## Creating a vendor
Click **+ New Vendor** at the top right of the list. The first step is a picker that searches as you type.
<Frame>
<img alt="New Vendor picker showing an existing vendor match and the create from scratch option" />
</Frame>
Type a company name or paste its website. Results fall into three groups:
| Group | What it means | What happens when you pick it |
| - | - | - |
| **Already in your workspace** | A vendor your organization already has. | **Open** takes you to that record. No new vendor is created. |
| **Directory** | A company in the Coverbase directory. Rows can carry a **Verified** tag and a count of how many organizations track it. | The record is created against that directory entry and its fields are prefilled. |
| **Add "name" manually** | Nothing matched. | A blank record with only the name. |
Some directory rows have product lines. Press the right arrow key on the row to see them, grouped as **Products from name** and **Companies owned by name**. Picking a product creates a vendor for that product, not for its parent. Slack and Salesforce, or AWS and Amazon, are separate companies with separate trust centers and documents, so pick the one you buy from.
<Warning>
**Pick the directory entry when there is one.** A vendor created against a directory entry is backed by shared company data. That is what feeds **Coverbase library documents** on the Documents tab, the prefilled company fields with a **Refreshed** date, and the subprocessor suggestions described in [Nth parties and subprocessors](#nth-parties-and-subprocessors). A vendor added manually gets none of that until Coverbase staff link it to an entity later.
</Warning>
After the picker, the wizard continues with **Modify Vendor Details** and, when your organization has vendor custom fields, **Fill in additional fields**. Fields the directory prefilled are collapsed under **Prefilled from the directory**; the ones you still have to fill sit under **Needs your input**, with required ones marked **Required by your organization**. The field-by-field walkthrough is in [Running an assessment, Path 2](/user-guides/running-an-assessment#path-2-alternative-creating-the-vendor-manually).
<Note>
Organizations that have not been switched to the directory picker see the older search field, *Select from existing vendors or create new\...*, with a **Create vendor from scratch** option at the bottom. The steps after that are the same.
</Note>
## The vendor page
Open a vendor and you land on **Overview**. The header carries the name (editable inline), an **Archived** badge if the vendor is archived, a **Coverbase AI** button, a **Vendor changes** button when something is waiting for review, and an **Actions** menu with **Build report**, **Export as Excel**, **Merge vendor** and **Archive**.
<Frame>
<img alt="Vendor overview page with sidebar cards and main cards" />
</Frame>
<Note>
Some workspaces have the newer vendor page, where the same content is arranged as sections listed down the left (**Overview**, **About**, **Documents**, **Assessments** and so on) instead of tabs across the top. The cards, fields and actions are the same; only where you click to reach them differs.
</Note>
### Sidebar cards
| Card | What it holds |
| - | - |
| **Team** | **Vendor Contacts** (people at the vendor: name, title, email, phone, LinkedIn), **Relationship Owners**, **Risk Analysts** and watchers. See [Team and owners](#team-and-owners). |
| **About** | **Website**, **Trust Center**, **Location**, **Description**, **Use Cases** and **Security Contact**. **AI Autofill** fills the empty fields from public sources; it never overwrites a value you typed. |
| **Properties** | **Inherent Risk** and **Residual Risk**, plus every custom field configured for vendors. The **+** menu offers **Set Inherent Risk Score**, **Set Residual Risk Score** and **Add custom field**. |
| **Services** | The vendor's active services. **Add Service** asks for a **Service Name** and **Service Description**. |
| **Tags** | The tags on the record, editable inline. |
| **Locations** | The vendor's sites, when the Risk module is on. See [Risk geography map](/user-guides/risk-geography-map). |
### Main cards
The main column is a card grid you can rearrange; what appears depends on your modules and your role. **Lifecycle** shows the status and moves it. **Quick actions** holds **Launch assessment**, **Launch zero-touch assessment** (with Zero Touch Assessments), **Send IRQ** and **Send vendor questionnaire** (with Know Your Vendor); its menu holds **Create new engagement** and **Upload contract**. Below them, a **Needs Attention** list shows IRQs still waiting on someone, open assessments, Radar alerts and recent emails. An IRQ the vendor has not submitted offers **Close request** to anyone who can edit portals; it closes the portal and drops the IRQ from the list. **Risk Profile** shows overall risk and a row per risk domain; **Inherent risk** shows the current level and the IRQs sent, with **Send IRQ** to send another. **Recommendation**, **Assessments**, **Documents**, **Engagements**, **Contracts**, **Tasks** (open findings: yours first, then those in progress, then soonest due), **Radar** and **Notes** each summarize their tab.
### Tabs
| Tab | What you find there |
| - | - |
| **Overview** | The cards above. |
| **Documents** | Every document on the vendor, grouped by assessment or service, plus a **Coverbase library documents** card. Library documents were collected by Coverbase from the vendor directly or from its trust center, reviewed by Coverbase staff, and can be pulled onto your record with **Import**. |
| **Assessments** | Split into **Full Assessments** and **Zero Touch Assessments**, groupable by year, control set or risk domain. |
| **Questionnaires** | Every questionnaire ever sent to this vendor, with **Sent**, **Submitted**, **Due Date**, **Respondent** and **Reviewer** columns. Archived templates still appear here; the submissions happened. |
| **Contracts**, **Obligations** | The vendor's contracts, with **Committed Value** and a **Needs Attention** list of deadlines, and the obligations extracted from them. See [Contracts workspace](/user-guides/contracts-workspace). |
| **Engagements** | The vendor's engagements. See [Services and engagements](#services-and-engagements). |
| **Vendor Intelligence** | Outside-in intelligence. See [Vendor Intelligence](#vendor-intelligence). |
| **Know-Your-Vendor** | Supplier onboarding and verified records, when that module is on. See [Supplier information](/user-guides/supplier-information). |
| **Activity** | The audit trail: every field change, status move and action, with who did it and when. |
| **Properties** | **Risk Profile**, **Risks**, **Business unit dependencies** and **Subprocessors / fourth parties**. |
| **Bill of Materials**, **Performance**, **Portals**, **Emails**, **Radar**, **Notes** | Uploaded SBOM files (see [Bills of materials](/user-guides/bill-of-materials)); scorecards and SLAs; the portals created for this vendor; email exchanged with the vendor; Radar alerts and detectors; the notes feed. |
Tabs that belong to another module (Contracts, Obligations, Radar, Assessments, Questionnaires) only appear when your role can read that resource. **Engagements** appears when your role can read services.
## Team and owners
The **Team** card names four kinds of people:
| Field | Who goes there | What it drives |
| - | - | - |
| **Vendor Contacts** | People at the vendor. | Prefills document requests and follow-ups you send. |
| **Relationship Owners** | The person or group on your side accountable for the supplier. | Notifications about the vendor, and the **Relationship Owners** filter and column. |
| **Risk Analysts** | The person or group doing the assessment work. | Assignment and the **Risk Analysts** filter. |
| **Watchers** | Anyone else who should hear about the vendor. | Notifications only. |
Owners and analysts can be a user group as well as a person. How groups route work is covered in [Assignment and delegation](/user-guides/assignment-and-delegation).
### People who do not have an account
A relationship owner is often a business owner who will never log in. When you open the **Relationship Owners** or **Add watchers** picker and the person is not there, choose **Add directory contact**. This creates a person who can be named on records and receives email about them, but cannot sign in. The email address must belong to your organization: on one of your declared email domains, or matching a person your identity provider syncs to Coverbase. Directory contacts always receive email for the notifications addressed to them, because they have no settings page to opt in from.
**Risk Analysts** is different: an analyst does the work and needs to sign in, so that picker creates a real user and needs the user create permission.
### The notification this sends
Assigning someone as a relationship owner sends **Relationship owner assigned**: an in-app notification by default, and an email if the person has turned that on in their settings. It reads "*name* assigned you as relationship owner for *vendor*" with a link to the page. The full catalog is in [Email and notifications](/user-guides/email-notifications).
## Statuses and lifecycle
A vendor has one lifecycle status. The **Lifecycle** card on Overview shows the current stage; **Set status** in its menu moves it, and **Configure lifecycle** takes an admin to the status configuration. On the list, **Update status** in the bulk bar moves several vendors at once.
Every organization starts with these six:
| Status | Meaning | Group |
| - | - | - |
| **Created** | The record exists. This is the default for a new vendor. | Unstarted |
| **Onboarding** | Onboarding is in progress. | Started |
| **Active** | The vendor is approved and in use. | Completed |
| **Inactive** | Not in use, but the record stays. | Canceled |
| **Discontinued** | The relationship has ended. | Canceled |
| **Denied** | The vendor was turned down. | Canceled |
An admin can rename, recolor, reorder and add statuses under **Configuration**. **Onboarding** and **Active** are system-managed: you can restyle them, but the onboarding panel and the default portfolio chart rely on them, so they cannot be renamed or removed. See [Configuring your data model](/user-guides/data-model-configuration).
<Note>
Status is not the same as archiving. **Inactive** or **Discontinued** keeps the vendor in every list and report. Archiving removes it. See [Merging and archiving](#merging-and-archiving).
</Note>
## Services and engagements
A vendor sells you things; a **service** is one of those things. An **engagement** is a piece of work with that vendor that has a start, an end and a status.
### Services
Add one from the **Services** card in the sidebar (**Add Service**, then a **Service Name** and **Service Description**), from the **Sheet 2: Service intake** tab of the bulk template, or by promoting a vendor into a service during a merge.
Click a service to open its own page at `/vendors/<vendor>/service/<service>`. It has the same shape as the vendor page: an **About Service** card, a team card, properties, tags and locations in the sidebar; **Lifecycle**, **Risk Profile**, **Inherent risk**, **Risks**, **Assessments**, **Documents** and **Notes** in the main column; and **Overview**, **Activity**, **Notes**, **Properties**, **Performance** and **Bill of Materials** tabs.
<Frame>
<img alt="Service details page with its own risk and assessment cards" />
</Frame>
Use a service when you need risk at a finer grain than the vendor. You can send an IRQ to a service and assess a service on its own, which keeps the scope tight and gives each product its own score. Whether those service scores roll up into the vendor's score is an organization setting; see [Decide whether service scores set the vendor's score](/user-guides/admin-setup#decide-whether-service-scores-set-the-vendors-score).
The **Actions** menu on a service page offers:
| Action | What it does |
| - | - |
| **Build report**, **Export as Excel** | The same PDF report and workbook as on the vendor page, for this service. |
| **Merge service** | Merges another service of the same vendor into this one. Shown when the vendor has another active service. |
| **Relink Vendor** | Moves the service under a different vendor, keeping its id and history. If records are attached, **Confirm move** first lists them: records linked only to this service move with it, and records shared with other services stay with the original vendor. |
| **Promote to Vendor** | Creates a standalone vendor from the service and archives the service. Risk scores, SLAs, performance scores and comments come across. Assessments, documents and contracts belong to the current vendor and stay with it, reachable from the archived service. |
| **Archive** | Archives the service. |
### Engagements
Create one from **Create new engagement** in the **Quick actions** card's menu on the Overview tab, from **New Engagement** on the Engagements tab, or from the **Engagements** view of the list. The form asks for a name (the placeholder suggests *2026 Annual Review*), a status, a description, a **Start Date** and an **End Date**, and lets you link **Services** and **Contracts** and name **Relationship Owners** and **Third-Party Contacts** up front.
An engagement's page lives at `/vendors/<vendor>/engagement/<engagement>`. The **About Engagement** card is where you link the vendor's **Services** and **Contracts** to it, so a renewal or a project points at the exact products and agreements it covers. **Engagement Term** holds the dates. The main column has its own **Lifecycle**, **Risk Profile** and **Inherent risk** cards, so an engagement can carry an IRQ of its own. Tabs are **Overview**, **Activity** and **Notes**. Engagements have their own statuses under **Configuration**, separate from vendor statuses, and are archived from their page or from the row menu on the **Engagements** view.
## Nth parties and subprocessors
An nth party is a company your vendor depends on: its cloud host, its payment processor, its support tooling. Coverbase keeps shared research on these dependencies, assembled from published subprocessor lists, SOC reports and the directory. Your organization keeps its own record of them on each vendor, and the shared research feeds that record as suggestions.
### On the vendor
Open the **Properties** tab and find **Subprocessors / fourth parties**.
<Frame>
<img alt="Subprocessors card with suggestions panel and linked subprocessors" />
</Frame>
To add one by hand, use the **Search or type a company name** box. Matching to a directory company gives the row a website and lets the graph and the risk chain treat it as the same company across vendors; a row with no match is only a name. Each row can carry a **Category**, an **HQ location**, an **Inherent Risk Level** and **Tags**.
**Edit** on a row opens **Edit Dependency**, your organization's own description of what the vendor relies on this company for: **Still a dependency**, **Dependency Type** (cloud infrastructure, payment processing, and so on), **Mode** (processor, reseller or OEM, integration), **Data in Scope** and **Notes**. Saving these details marks the link as yours, and Coverbase stops suggesting changes to it.
Two badges matter:
| Badge | Meaning |
| - | - |
| **Inherited** | Coverbase's shared research suggested this subprocessor and it was accepted. Editing it stops later updates from overwriting your changes. |
| **Dependency ended** | Your record says the vendor no longer depends on this company. |
**Remove** archives the link. Removal is permanent: a removed subprocessor is never suggested again for that vendor, even if the shared research still lists it. You can add it back by hand.
### Suggestions, with or without review
The **Suggested Subprocessors** panel lists what the shared research knows that your record does not: a new dependency, a change to one you have (**Updated**), or one that has ended (**Dependency ended**). **Check for new** runs the comparison for this vendor on demand; it also runs when a vendor first gains its directory entry and nightly for every vendor. Accept or reject rows singly, or **Accept all** / **Reject all**. Rejecting is durable: the suggestion does not come back.
Whether suggestions wait for you at all is an organization setting, **When Coverbase Finds a New Subprocessor**, on **Configuration → Subprocessors**. It is there for every organization, whether or not Know Your Vendor is turned on, and changing it needs permission to update organization settings.
| Setting | Behavior |
| - | - |
| **Add it automatically** | New dependencies land on the vendor without review. This is the default. |
| **Queue it for review under Vendor changes** | Suggestions wait in the panel and in the **Vendor changes** queue until someone decides. |
| **Do not add anything** | The research is ignored. |
When suggestions are queued, the vendor page header shows **Vendor changes** with a count. It opens the review queue for that vendor. The same rows are decided from the Properties tab. When nothing is waiting, for one vendor or for the whole organization, the page says **Nothing Waiting for Review** and names what would wait there.
<Note>
Suggestions come only from companies Coverbase has researched. A dependency your vendor disclosed that is not in the shared graph has to be added by hand. A vendor that was added manually, with no directory entry behind it, gets no suggestions at all.
</Note>
### The Nth Parties view
Back on the list page, switch to **Nth Parties**. The table has **Nth Party Name**, **Website**, **Inherent Risk Level**, **Description**, **Tags** and **Vendors** columns; the row menu lists which of your vendors depend on it. The relationship graph sits beside the table. Clicking a row highlights it in the graph; clicking a vendor node filters the table to that vendor's nth parties, and clicking an nth-party node filters it to that one. **Reset view and filters** clears it. The graph opens full screen at `/vendors/nth-party-graph` (search the command palette for *Nth Party Graph*), where **Export as SVG** saves it.
<Frame>
<img alt="Nth parties table beside the relationship graph" />
</Frame>
## Merging and archiving
There is no delete for a vendor. The two ways to make one go away are to merge it into another or to archive it.
### Merging
From a vendor's page, **Actions → Merge vendor** asks you to pick another vendor. Everything on the selected vendor moves into the one you are on, and the selected vendor is archived. Where both have a value for the same field, the vendor you are on wins; where only one does, that value is kept.
From the list, **Actions → Merge Vendors** scans the whole portfolio for likely duplicates, grouped by **Same domain**, **Same brand, different TLD**, **Same name** and **Similar name**. Pick a primary in each group and a strategy:
| Strategy | Result |
| - | - |
| **Merge as equals** | Combine all data into the primary and archive the duplicates. |
| **Convert non-primary to service** | The non-primary vendor becomes a service of the primary. Its services move across and its assessments are combined. |
| **Archive duplicates** | Keep the primary and archive the others without moving data. |
Merge before you bulk-upload documents: the ZIP uploader rejects a folder whose name matches more than one vendor.
### Archiving
**Actions → Archive** on the vendor page, **Archive** in the row menu, or **Archive** in the bulk bar. The confirmation says what goes with it: the vendor's assessments, issues, tasks, documents and obligations are archived too.
After archiving, the vendor disappears from the list and from pickers. Its page still opens with an **Archived** badge, and the **Archived** filter brings it back into the list. There is no unarchive button in the dashboard.
## Who can do what
| Action | Needs |
| - | - |
| See the list and a vendor's page | Read access to vendors. Roles limited to assigned records see only those. |
| Edit fields, team, tags, services, status | Update access to vendors. Members and admins have it; a member limited to assigned vendors has it on vendors they are named on. |
| Create a vendor or bulk create | Vendor create access. |
| Archive | The vendor archive permission. The item is grayed out with a tooltip when you lack it. |
| Export as Excel, portfolio report | The vendor export permission (service export for the services workbook). |
| Add a directory contact | Update access to vendors. Adding a risk analyst who needs an account requires user create access. |
Roles and how permissions are built: [Permissions and roles](/user-guides/permissions-and-roles).
## Vendor Intelligence
The **Vendor Intelligence** tab is where Coverbase's outside-in research on the company appears. Each section has its own guide, and this page does not repeat them: the two headline cards in [Financial health and security intelligence](/user-guides/vendor-fact-sheet), then [Security intelligence](/user-guides/security-intelligence), [Financial health](/user-guides/financial-health-score), [Corporate registrations](/user-guides/corporate-registrations), [People intelligence](/user-guides/people-intelligence) and [Sanctions screening](/user-guides/sanctions-screening). The product overview is at [Vendor Intelligence](/products/vendor-intelligence).
The overview's header holds **Refresh all**, which refreshes the vendor's intelligence, then **Export**. With Zero Touch Assessments, the **Latest Zero Touch Assessment** card shows the vendor's most recent run with its score. Click the run to open its result, or click the run count (for example, **View all 3 runs**) to open the Zero Touch Assessments list filtered to this vendor.
Each detail page shares one header. **Refresh** comes first, then the page's own buttons, then the actions menu (**...**). Hover over **Refresh** to see when the page was last refreshed and who or what started it. When the window is too narrow, the page's own buttons move into the actions menu.
### Exporting Vendor Intelligence
**Export** on the Vendor Intelligence overview opens a dialog that lists the overview and each detail page this vendor has: corporate registrations, people intelligence, security posture, financial health and, where your organization screens vendors, sanctions screening. Tick the pages you want and choose **Export PDF** or **Export Excel**.
* The PDF starts with the overview: the company, an **At a Glance** row with each detail page's headline score or result, key figures, the company profile, products, key people, reviews, news, competitors, compliance and legal actions, the security program and nth parties. Each ticked detail page follows on its own pages, set exactly as that page's own **Export PDF** sets it, peer comparison included.
* The Excel workbook takes the same selection, one sheet per page, so the two files always hold the same sections.
* Names in non-Latin scripts, such as a Japanese or Korean legal name, print in a matching font.
## Troubleshooting
| What you see | What is happening |
| - | - |
| "The vendor I added has no library documents and no subprocessor suggestions." | It was added manually, so no directory entry backs it. Search the picker again for the company; if it exists in the directory, ask your Coverbase contact to link the record to it. |
| "The picker keeps showing **Open** instead of creating." | The company is already a vendor in your workspace. Open it rather than creating a duplicate. |
| "I cannot find a vendor that used to be here." | It was archived, or merged into another vendor. Add the **Archived** filter on the list; a merged vendor's activity names the record it was merged into. |
| "**Archive** is grayed out." | Your role lacks the vendor archive permission. Hover the item for the tooltip. |
| "A subprocessor I removed is missing from the suggestions." | Removal is permanent by design. Add it back by hand from the search box. |
| "Suggestions are being added without anyone approving them." | The organization setting is **Add it automatically**. Change it to **Queue it for review under Vendor changes** on **Configuration → Subprocessors**. |
| "I set a vendor to **Inactive** but it still appears everywhere." | Status does not hide a record. Archive it if you want it out of lists and pickers. |
| "I added a relationship owner but they never got an email." | The in-app notification is on by default; the email is off until that person turns it on in their settings. Directory contacts are the exception and are always emailed. |
## Related
<CardGroup>
<Card title="Running an assessment" icon="clipboard-check" href="/user-guides/running-an-assessment">
From a vendor record to a completed assessment, including the manual create walkthrough.
</Card>
<Card title="Requesting a new vendor" icon="inbox" href="/user-guides/requesting-a-vendor">
The intake path, which creates or links the vendor with due diligence attached.
</Card>
<Card title="Admin setup" icon="sliders" href="/user-guides/admin-setup">
Importing the portfolio and designing the tag structure.
</Card>
</CardGroup>
# Warehouse data share
Source: https://docs.coverbase.com/user-guides/warehouse-data-share
Add a Snowflake, Amazon S3 or BigQuery destination, test it, sync it hourly or daily, read the run log and the table contract, and point Power BI or Tableau at the current views.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers **Configuration → Data Share** and the **Distribution** card on **Program Overview**. It sits beside [Exporting and scheduling dashboards](/user-guides/dashboard-exports) and [Integration Hub](/user-guides/integration-hub). Each destination has a setup guide: [Snowflake](/integrations/guides/snowflake), [Amazon S3](/integrations/guides/amazon-s3) and [BigQuery](/integrations/guides/bigquery). For what the module is, see [Warehouse data share](/products/warehouse-data-share).
</Info>
<Note>
Your Coverbase representative turns on the third-party lifecycle features, including data share, for your organization.
</Note>
Data share writes your third-party risk tables into your own warehouse or bucket on a schedule. Your BI tools read them there.
The mistake people make most often is building a report on the raw tables. Each sync appends changed rows, so a raw table holds several versions of the same record. Build on the `<table>_current` views, or deduplicate S3 files on `id` keeping the latest `_cb_synced_at`.
## Step 1: Prepare the destination
Before you open Coverbase, prepare the account on your side. The provider guides have the exact grants:
* **Snowflake:** a user with a key pair (the public key set as `RSA_PUBLIC_KEY`) and a role with `USAGE` on the warehouse, database and schema, and `CREATE TABLE` and `CREATE VIEW` on the schema.
* **BigQuery:** a service account with BigQuery Data Editor on the dataset and Job User on the project. The dataset is created if it does not exist.
* **Amazon S3:** a bucket and an IAM role with `s3:PutObject` under the prefix. You finish its trust policy after saving (step 3).
## Step 2: Add the destination
Open **Configuration** and choose **Data Share**. Click **Add destination**.
<Frame>
<img alt="Data Share page with an Add destination button, no destinations yet, and the Table Contract listing eighteen tables such as third_parties, engagements, services, assessments, findings and contracts with their sync type and column count" />
</Frame>
1. Give it a **Name**, choose the **Type** (**Snowflake**, **Amazon S3** or **BigQuery**) and how often to **Sync** (**Hourly** or **Daily**).
2. Fill in the fields for the type:
| Type | Fields |
| - | - |
| Snowflake | **Account**, **User**, **Role**, **Warehouse**, **Database**, **Schema**, **Private Key (PEM)** and an optional **Key passphrase** |
| Amazon S3 | **Bucket**, **Prefix**, **Region**, **IAM Role ARN**, **File Format** (**CSV (gzip)**, **JSON Lines (gzip)** or **Parquet (snappy)**) |
| BigQuery | **Project ID**, **Dataset**, **Location**, **Service Account Key (JSON)** |
3. Click **Add destination**.
Credentials are stored encrypted the moment you save and are never shown again. The card shows only a hint: the key's fingerprint for Snowflake, or the service account's email for BigQuery. To change a credential, **Edit** the destination and enter a new one. Leave the field empty to keep the stored one.
## Step 3: Finish the S3 trust policy
When you save an S3 destination, **Finish S3 Setup** opens with the destination's **External ID** and a ready-made **Trust Policy** naming the Coverbase principal. **Copy** it and paste it into the role's trust relationship in the AWS console, then click **Done**. The destination card keeps the external ID and policy under **Role trust policy** if you need them again. Coverbase assumes the role only with that external ID, which is generated for this one destination and starts with `coverbase-`.
## Step 4: Test and sync
Click **Test connection**. **Coverbase wrote to the destination.** means the credentials and grants work. If it fails, **The destination rejected the test** says what to fix in plain terms: a trust policy that refused the role, a missing bucket, a role that cannot write under the prefix, a wrong region, or a warehouse that cannot be reached. Then click **Sync now** for the first sync, or wait for the schedule.
The card shows health: **Live**, **Failing**, **Paused**, **Pending** or **Needs credential**. **Run log** lists each run's **Started**, **Status**, **Trigger** (**Scheduled** or **Sync now**), **Rows** and **Tables**, a page at a time. **Show run details** gives the rows written per table and, for a failed run, **What went wrong**. A failed run is retried from the same point by the next one, so nothing is skipped.
**Pause syncing** and **Resume syncing** stop and restart the schedule. **Archive** stops syncing and deletes the credential. Tables already written stay in your warehouse.
## Step 5: Model on the current views
**Table Contract** on the Data Share page lists every table, whether it syncs **Changed rows** or a **Full snapshot**, and its columns. Every `*_level_id` column joins to `risk_levels.id`, and every `status_id` to `statuses.id`.
* In Snowflake and BigQuery, point Power BI or Tableau at the `<table>_current` views.
* In S3, read the files under `<prefix>/<table>/synced_date=YYYY-MM-DD/`, deduplicate on `id` keeping the latest `_cb_synced_at`, and read each table's columns from `<prefix>/_contract/<table>.json`.
Timestamps are UTC. Archived records stay with `is_archived` set. Columns are only ever added, never renamed or removed in place.
## Where it shows
The **Distribution** card on [Program Overview](/user-guides/program-insights), under **Dashboards**, lists each destination with its table count and last sync, beside the board pack schedule and your scheduled dashboard emails. **Manage** opens the Data Share page.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| **The destination rejected the test** | A grant is missing, or the key, service account or role is wrong. | Check the grants in the provider guide. |
| An S3 test fails with access denied | The role's trust policy does not name the Coverbase principal or require the external ID. | Copy the trust policy from the destination card. |
| The health reads **Needs credential** | The credential was never saved or was removed. | **Edit** the destination and enter it. |
| A **Sync now** did nothing | A scheduled sync of the same destination was already running. | Expected. Check the run log after it finishes. |
| Rows appear more than once | You are reading the raw tables. | Read the `_current` views, or deduplicate on `id`. |
| A deleted service is still in the share | Deleted rows are not sent, except through the services snapshot. | Read `services_current`, which keeps only the latest run. |
## Related
<CardGroup>
<Card title="Exporting and scheduling dashboards" icon="file-export" href="/user-guides/dashboard-exports">
Dashboard emails on the same Distribution card.
</Card>
<Card title="Export API concepts" icon="arrow-up-from-bracket" href="/export-api-concepts">
Pulling data through the API instead.
</Card>
<Card title="Integration credentials and signing" icon="key" href="/security/integration-credentials">
How destination credentials and S3 roles are protected.
</Card>
<Card title="Warehouse data share" icon="database" href="/products/warehouse-data-share">
What the module does.
</Card>
</CardGroup>
# Webhooks
Source: https://docs.coverbase.com/user-guides/webhooks
Add, test and manage webhook endpoints from Configuration: choose the events each endpoint receives, set its signing secret, send a test event, and read its delivery history.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the **Webhooks** page under **Configuration**, where you register the endpoints Coverbase sends events to. It sits beside [Email and notifications](/user-guides/email-notifications) and [White-labeling your vendor-facing domain](/user-guides/white-labeling). For the event catalog, the payload, the request headers and how to verify a signature, see the [Webhooks reference](/integrations/webhooks). To manage the same endpoints from code, see the [Webhooks API](/api-reference/webhooks).
</Info>
A webhook is an HTTPS endpoint of yours that Coverbase calls when something changes in your workspace: a vendor is created, an assessment moves to a new status, a finding is raised. Each call is a `POST` with a JSON body, signed with a secret that only you and Coverbase hold, so your receiver can prove the call came from Coverbase before it acts on it.
An endpoint receives events in two ways. It receives every event it is subscribed to on the **Webhooks** page, and it receives whatever a workflow's **Send webhook** step addresses to it. Every attempt either way is recorded in the endpoint's delivery history.
The mistake people make most often is saving the webhook before the signing secret is stored where the receiver can read it. Coverbase never shows the secret again after you save, so the only fix is to set a new one and update the receiver.
## Opening the page
Open **Configuration** at the bottom of the left navigation and choose **Webhooks** in the **Developers and integrations** group, or type "webhook" into **Search configurations...**. The page opens for the Admin and Member roles only. Only an Admin can add, edit, test or delete an endpoint; a Member sees the list and the delivery history, with **Only admins can add, change, test or delete webhooks.** where the **Add webhook** button would be. A person with a custom role does not see the page, whatever the role grants; see [Permissions and roles](/user-guides/permissions-and-roles).
<Frame>
<img alt="The Coverbase Webhooks page listing three endpoints with their events, status, health and created date, and the four row actions" />
</Frame>
| Column | What it shows |
| - | - |
| **Endpoint URL** | The URL Coverbase calls, with the description underneath. |
| **Events** | The first three subscribed events, then **+2 more** and so on. Hover the extra badge to see the rest. **No events** means the endpoint only receives what a workflow sends it. |
| **Status** | **Enabled** or **Disabled**. |
| **Health** | The status of the most recent delivery, with the share of recorded attempts marked **delivered** underneath (each retry counts as an attempt). It reads **No deliveries** until the first attempt. Once there are deliveries, click it to open the delivery history. |
| **Created** | When the endpoint was added. |
Four icons end each row: **Send test**, **Delivery history**, **Edit** and **Delete**. Hover an icon to see its name. The **Webhook documentation** link under the page title opens the [Webhooks reference](/integrations/webhooks).
## Adding an endpoint
Have the receiver running before you start, and decide on a secret: a random string of at least 16 characters. Coverbase does not generate one for you.
<Steps>
<Step title="Open the form">
Click **Add webhook** at the top right of the page.
</Step>
<Step title="Enter the endpoint">
Type the full address in **Endpoint URL**. It has to start with `https://`. Coverbase refuses a URL that carries a username or password, uses a non-standard port, or points at a private, loopback, link-local or cloud metadata address. The rules are in [URL restrictions](/integrations/webhooks#url-restrictions).
</Step>
<Step title="Set the signing secret">
Type or paste the secret into **Signing secret**. The eye icon shows what you typed. Copy it into your receiver's configuration now, before you save.
</Step>
<Step title="Choose the events">
Open **Events** and tick the events this endpoint should receive. See [Choosing events](#choosing-events) below. Leave it empty for an endpoint that should only receive what a workflow sends it.
</Step>
<Step title="Label it">
Add a **Description**, such as the system that owns the endpoint. It appears under the URL in the list and in a workflow's **Target webhooks** picker, where it is often the only way to tell two endpoints apart.
</Step>
<Step title="Save">
Leave **Enabled** on and click **Add webhook**. Coverbase confirms with **Webhook created.**
</Step>
</Steps>
<Frame>
<img alt="The Coverbase Add webhook dialog with an endpoint URL, a masked signing secret, five events selected, a description and the Enabled switch on" />
</Frame>
<Warning>
**The signing secret is shown once, while you type it.** After you save, neither the list nor **Edit** shows it again. If you lose it, set a new one (see [Changing the secret](#changing-the-secret)) and update the receiver at the same time.
</Warning>
## Choosing events
The **Events** picker lists every event Coverbase emits, by a readable name: **Vendor Created** is the `Vendor.Created` event, **Assessment Updated** is `Assessment.Updated`. Type in the search box to narrow the list, and tick as many as you need. The field then reads **5 selected** or similar. What each event carries in its payload is in the [event catalog](/integrations/webhooks#event-catalog).
<Frame>
<img alt="The Coverbase Events picker open over the Add webhook form, filtered to assessment events, with Assessment Created and Assessment Updated ticked" />
</Frame>
Three things are worth knowing before you tick:
* **An Updated event fires on every edit.** A webhook subscribed to **Vendor Updated** receives every change to every vendor, including a typo fix. There is no field filter on a webhook. If your receiver only cares about some changes, leave the event off the webhook and send it from a workflow that names this endpoint in **Target webhooks**. There, the trigger can watch specific fields and conditions can narrow it further (see [Sending events from a workflow](#sending-events-from-a-workflow)).
* **One name does not follow the pattern.** `WorkflowRun.Created` is listed as **Running the workflow**.
* **Monitoring record events are listed only when your workspace uses monitoring records.**
## Testing an endpoint
Send a test before you rely on an endpoint, and again after you change the receiver or the secret.
<Steps>
<Step title="Open the test dialog">
Click the **Send test** icon (the paper plane) on the endpoint's row. The **Send a test event** dialog opens.
</Step>
<Step title="Pick the event type">
**Event type** starts on `webhook.test`, whose payload is `{"test": true}`. Pick a real event type instead to send a sample of that event's payload. **Example payload** shows the body your endpoint will receive; the `event_id` and `occurred_at` are filled in when the test is sent.
</Step>
<Step title="Send it">
Click **Send test event**. Coverbase queues the test and confirms with **Test event queued for delivery.** The attempt appears in the endpoint's delivery history a few seconds later.
</Step>
</Steps>
<Frame>
<img alt="The Coverbase Send a test event dialog showing the Event type selector set to Vendor Updated and the example JSON envelope" />
</Frame>
A test with a real event type carries sample IDs that do not exist in your workspace. A receiver that reads the record back through the API gets a not-found error, which is expected. Test with `webhook.test` if your receiver cannot tolerate that.
**Copy as cURL** copies the same test as a command against the [test endpoint of the Webhooks API](/api-reference/webhooks#test-a-webhook). It expects two environment variables: `COVERBASE_API`, the API base URL, and `COVERBASE_API_KEY`, an API key.
<Tip>
To bring a new endpoint online without surprises, add it with no events selected, send a test, and check the result in **Delivery history**. Once the receiver answers with a `2xx` and verifies the signature, edit the webhook and add its events.
</Tip>
## Reading delivery history
Click the **Delivery history** icon on a row, or click the endpoint's **Health** value. The dialog lists every recorded attempt for that endpoint, newest first, 50 to a page. **Previous** and **Next** move between pages.
| Column | What it shows |
| - | - |
| **Event** | The event type the delivery carried, such as `Vendor.Created` or `webhook.test`. **View payload** expands the `data` object that was sent. |
| **Status** | The outcome of the attempt, with the reason underneath when it failed. |
| **Response** | The HTTP status your endpoint returned and how long it took, or a dash when there was no response. |
| **Attempted** | When the attempt was made. |
| Status | What it means |
| - | - |
| **delivered** | Your endpoint answered with a `2xx` status. The status and the time it took are in **Response**. |
| **timeout** | Your endpoint did not answer within 10 seconds. |
| **error** | The attempt failed. The reason is under the badge: a non-`2xx` status from your endpoint, a connection failure, or a URL Coverbase refused to call because it resolved to a private or internal address when the delivery was made. |
A failed delivery is tried again when a later attempt could succeed: after a timeout, a connection failure, or a `408`, `429` or `5xx` status. Coverbase makes up to six attempts, waiting about 4 seconds, 16 seconds, 64 seconds, then 4 minutes twice between them, and records each attempt as its own row with the same event ID. Any other `4xx` or `3xx` status, a refused URL and a test event are not retried. Each retry is signed again with a new timestamp, so make your receiver idempotent on the event ID: a delivery that succeeded but answered too slowly can arrive twice.
The **Status** filter at the top narrows the page you are looking at, not the whole history, so page through with **Previous** and **Next** when you are hunting for older failures. Coverbase keeps each attempt for 90 days. What each recorded field means, and how to read the same history through the API, is in [Webhook delivery history](/integrations/webhook-deliveries).
## Editing, pausing and deleting
Click the **Edit** icon to open **Edit webhook**. It is the same form, with the current URL, events, description and status filled in. Click **Save changes** to apply an edit, and Coverbase confirms with **Webhook updated.** The next delivery uses the new settings.
<Frame>
<img alt="The Coverbase Edit webhook dialog with the signing secret field empty and the help text Leave blank to keep the existing secret" />
</Frame>
### Changing the secret
**Signing secret** is always empty in **Edit webhook**, and saving with it empty keeps the current secret. To replace it, type a new secret of at least 16 characters and click **Save changes**. Deliveries are signed with the new secret from then on, so update the receiver at the same moment. A receiver still checking the old secret rejects everything in between.
### Pausing an endpoint
Turn **Enabled** off and save. The row shows **Disabled**, and the endpoint stops receiving events: subscribed events are not sent to it, and a workflow step that names it skips it. Events that happen while it is disabled are not sent to it later when you switch it back on.
### Deleting an endpoint
Click the **Delete** icon. **Delete webhook?** warns that this stops all event deliveries to the URL and cannot be undone; click **Delete webhook** to confirm. You can no longer open its delivery history afterwards, so look up anything you need from it first. A workflow step that named the endpoint skips it from then on.
## Sending events from a workflow
A workflow can send its triggering event to your endpoints with the **Send webhook** action, which you find under **Webhook** in the action picker. Use it when an endpoint should only hear about some changes, such as a vendor moving to a particular status, or when the delivery should wait until other steps are done.
| Field | What it does |
| - | - |
| **Event type** | **Use the triggering event** by default. Pick another event type only if the receiver expects the delivery labeled as that type. |
| **Target webhooks** | **All subscribed webhooks** by default: every enabled endpoint subscribed to the event. Choose one or more endpoints to deliver to them directly, whatever they are subscribed to. |
The line under the fields tells you before you save how many enabled endpoints will receive the delivery, or that the step will be skipped because none will. How to build the rest of the automation is in [Building a workflow](/user-guides/building-a-workflow). A delivery made by a workflow also appears on that run's step, with the request and the response, when you open the run.
## Troubleshooting
| What you see | Cause | Fix |
| - | - | - |
| **URL must start with https\://** under **Endpoint URL** | The address starts with `http://` or has no scheme. | Serve the receiver over HTTPS and enter the full `https://` address. |
| **Failed to create webhook.** followed by a message about private, link-local, loopback or metadata addresses | The URL points inside a private network, includes credentials, or uses a non-standard port. | Use a public HTTPS address on the standard port. A receiver inside your network needs a public proxy in front of it. |
| **Secret must be at least 16 characters.** | The secret is too short. | Use a longer random string. |
| The endpoint shows **No deliveries** and nothing arrives | The webhook has no events, is **Disabled**, or none of its events has happened yet. | Check **Events** and **Status**, then use **Send test** to prove the path end to end. |
| The receiver rejects every delivery as a bad signature | The receiver holds a different secret, or it verifies the parsed JSON instead of the raw request body. | Set a new secret in **Edit webhook** and give the receiver the same value. Verify against the raw body, as shown in [Signature verification](/integrations/webhooks#signature-verification). |
| Attempts show **timeout** | The receiver took longer than 10 seconds to answer. | Answer with a `2xx` as soon as the request arrives and do the work afterwards. |
| The receiver fails on a test event with a not-found error | A test with a real event type carries sample IDs, not records from your workspace. | Expected. Test with `webhook.test`, or make the receiver tolerate unknown IDs. |
| **Test event queued for delivery.** but nothing in **Delivery history** | The attempt had not run yet when you looked. | Wait a few seconds, then close and reopen **Delivery history**. |
| The **Status** filter shows nothing though the endpoint has deliveries | The filter only narrows the page you are on. | Move through the pages with **Previous** and **Next**. |
| A workflow's **Send webhook** step says it will be skipped | No enabled endpoint is subscribed to the event, or the endpoints it names are disabled or deleted. | Enable the endpoint, subscribe it to the event, or pick it in **Target webhooks**. |
| **Webhooks** is missing from **Configuration**, or **Configuration** is missing | The page opens only for the Admin and Member roles. A custom role never sees it. | Ask an Admin to add or change the endpoint. |
| There is no **Add webhook** button, and rows have no **Send test**, **Edit** or **Delete** | You are a Member. Only an Admin manages endpoints. | Ask an Admin to make the change. |
## Related
<CardGroup>
<Card title="Webhooks reference" icon="arrow-right-from-bracket" href="/integrations/webhooks">
The event catalog, the delivery envelope, the request headers and signature verification.
</Card>
<Card title="Webhook delivery history" icon="list-check" href="/integrations/webhook-deliveries">
What each recorded attempt holds, and how to read the history through the API.
</Card>
<Card title="Webhooks API" icon="code" href="/api-reference/webhooks">
Register, update, test and delete endpoints from code.
</Card>
<Card title="Building a workflow" icon="diagram-project" href="/user-guides/building-a-workflow">
Triggers, conditions and the Send webhook action, for deliveries that should only happen sometimes.
</Card>
</CardGroup>
# White-labeling your vendor-facing domain
Source: https://docs.coverbase.com/user-guides/white-labeling
Send vendor emails and host the portal on your own subdomain instead of coverbase.ai and coverbase.app, and choose between Coverbase-managed and organization-managed DNS.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. It covers the vendor-facing *domain*: the subdomain vendor emails come from and the portal is hosted on. For logo, color, and layout branding, see [Step 1 of the Admin and setup guide](/user-guides/admin-setup#step-1-organization-users-and-branding) and [Applying your own branding](/user-guides/email-notifications#applying-your-own-branding).
</Info>
By default, Coverbase sends vendor email from `mailer@coverbase.ai` and vendors submit documents through `dashboard.coverbase.app`. That works with no setup. Most customers white-label it and host the vendor experience on their own subdomain instead.
## Why white-label
* **Higher response rates.** Vendors are more likely to open and act on email from a domain they recognize.
* **Unified branding.** Your organization's identity stays consistent through the whole vendor interaction, not only inside the email body.
* **Reduced friction.** Fewer "is this a phishing attempt?" questions for your security team.
## Before you start
You need:
* A dedicated subdomain you control, such as `vendors.yourorg.com`. Do not use your root domain, since Coverbase needs its own DNS records without touching the rest of your mail and web setup.
* A chosen email prefix, such as `outreach@`, for the address vendor email will send from.
* Either the ability to delegate that subdomain's nameservers, or access to create records directly with your DNS provider.
Talk to your Coverbase contact to kick off setup. They confirm your subdomain and email prefix and help you pick one of the two paths below.
Once the domain is live, the address shows as **Outbound sender email** under **Organization identity** on **Configuration → Communications**. Only Coverbase can change that field, so ask your Coverbase contact when the address needs to move. Admins can edit the sender name and the inbound contact email on the same page themselves.
## Two ways to set it up
| | Coverbase-managed DNS (recommended) | Organization-managed DNS |
| - | - | - |
| **You do** | Delegate NS records for the subdomain to Coverbase | Create and maintain around 10 to 12 individual records yourself |
| **Coverbase does** | Configures and maintains TLS certificates, inbound/outbound email, and web routing | Provides the exact record values; you keep them current |
| **Timeline** | Fully operational within 24 hours of provisioning | 1 to 2 weeks, due to manual coordination and troubleshooting |
| **Choose it when** | Your policy allows delegating a subdomain's nameservers | Your organization's policy prevents Name Server delegation |
### Option 1: Coverbase-managed DNS (recommended)
This is the lowest-maintenance option for your IT team.
Provision **NS (Name Server) records** for your chosen subdomain, pointing to Coverbase. Once delegated, Coverbase handles the configuration and ongoing maintenance of TLS certificates, inbound and outbound email traffic, and web routing on that subdomain. You do not need to touch DNS again after the initial delegation.
<Tip>
Choose this path unless your organization's policy specifically prevents delegating a subdomain's nameservers to a third party. It is less setup work now and no maintenance later.
</Tip>
### Option 2: Organization-managed DNS
Choose this if your organization's policy prevents Name Server delegation. Your team creates and manages the individual records instead, which typically takes 1 to 2 weeks due to the manual coordination and troubleshooting involved.
Your Coverbase contact provides the specific record values once your subdomain is confirmed. The categories you provision:
| Category | Record type | Purpose |
| - | - | - |
| Outbound email | `TXT`, `CNAME` | DKIM and Return Path |
| Inbound email | `MX`, `TXT` | Routes vendor replies back to the Coverbase platform |
| Web traffic | `A` | Directs traffic from your subdomain to the API and dashboard servers |
| Security & auth | `CNAME` | TLS certificate validation and secure authentication through the identity provider (Clerk) |
<Warning>
These are placeholder categories, not values. Wait for your Coverbase contact to send the specific records for your subdomain rather than guessing at them, and keep them current on your end since Coverbase does not manage records under this path.
</Warning>
## Related guides
<CardGroup>
<Card title="Admin and setup guide" icon="sliders" href="/user-guides/admin-setup#step-1-organization-users-and-branding">
Step 1 covers organization, users, and logo branding, the setup that happens before or alongside white-labeling.
</Card>
<Card title="Email and notifications" icon="envelope" href="/user-guides/email-notifications#applying-your-own-branding">
How your logo and brand color flow into the emails sent from your white-labeled domain.
</Card>
</CardGroup>
# Workflow templates
Source: https://docs.coverbase.com/user-guides/workflow-templates
The nineteen ready-to-run automations Coverbase ships: what each one does, what you have to change before turning it on, and how to make one your own.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. Read it when something in your program keeps slipping (a request nobody picks up, a renewal that passes in silence, a finding with no clock on it) and you want to know what is already built before you build an automation from scratch.
</Info>
A workflow in Coverbase watches for something happening: a request submitted, a vendor created, a contract date moved. Then it does something about it. Building one means picking a trigger, adding the gates that narrow it, and configuring the record it writes. That is an hour's work, and most of the automations a third-party program needs are the same nineteen.
Open them from **Workflows** → **Browse templates**. Pick one, read what it does, apply it, work through the short list of things it says to change, then switch it on.
<Frame>
<img alt="The Coverbase workflow template gallery, showing template cards, lifecycle shelves and a detail pane" />
</Frame>
<Note>
Applying a template makes a copy you own. The workflow, its steps and its conditions become ordinary records in your workspace, editable like any other. Rename them, change the triggers, add gates, delete steps. Nothing syncs back: later changes to the Coverbase template never reach your copy, and your edits never leave your workspace.
</Note>
<Warning>
**An applied workflow arrives switched off.** Every template writes real records against live vendors (tasks, assessments, register entries), so applying one lands you in the editor with the steps drawn and the **Enabled** toggle off. Read the steps, work the setup list, then turn it on.
</Warning>
## The nineteen templates
Shelves follow the third-party lifecycle rather than the records the templates write, so the one you want is usually where the problem happens. **Routing** is the exception and sits last, because it is not a moment in that lifecycle but a rule applied across all of them.
| Template | Shelf | Starts when | Steps | Needs |
| - | - | - | -: | - |
| **Risk-tiered intake routing** | Intake | A request is submitted | 4 | Intake |
| **Intake to onboarding assessment** | Intake | A request is submitted | 2 | Intake |
| **Purchase request approval chain** | Intake | A request is submitted | 6 | Intake, Purchase requests |
| **New vendor onboarding, assessment to decision** | Onboarding | A vendor is created | 5 | none |
| **High inherent risk escalation** | Risk triage | A vendor's risk score changes | 2 | Risk register |
| **Bank detail change verification** | Risk triage | A vendor's bank details change or an account is added | 2 | none |
| **Screening match adjudication** | Risk triage | Screening raises a match | 2 | Screening |
| **Two-level assessment sign-off** | Assessments | An assessment reaches the Review results stage | 5 | none |
| **Zero-touch assessment launch** | Assessments | An assessment is created | 2 | none |
| **Evidence collection handoff** | Assessments | Automatic collection gives up | 2 | none |
| **Reassessment scoping from the monitoring record** | Assessments | A vendor's next assessment comes due | 2 | Monitoring records |
| **Finding remediation and vendor commitments** | Remediation | A finding is raised, or a vendor commitment recorded | 2 | none |
| **Contract review, approval handoff and execution** | Contracts | A contract is added | 5 | Contracts |
| **Contract renewal runway and expiry** | Contracts | A renewal or notice date moves, or a term runs out | 2 | Contracts |
| **Contract obligation ownership** | Contracts | An obligation is raised | 2 | Contracts, Obligations |
| **Monitoring signal triage** | Monitoring | Monitoring raises a signal | 2 | Radar |
| **Monitoring record turned not clean** | Monitoring | A vendor's monitoring record turns Not clean | 2 | Monitoring records |
| **Vendor offboarding with sign-off** | Offboarding | A vendor record is archived | 4 | none |
| **Route work to the vendor's owner** | Routing | Any task is raised, or a vendor is created | 2 | none |
Every template has at least two steps. A one-step rule is something you can build in a minute; what the library adds is the sequence around it: the kickoff after the assessment, the second check after the first, the sign-off after the last exit task.
### Which modules a template needs
The library hides a template your workspace cannot run, so you never adopt an automation whose trigger can never fire. A hidden template takes its shelf with it when it is the last one there: a workspace without Contracts never sees a **Contracts** tab at all.
A module counts as available only when both halves are true. The feature gate says your organization has the module, and your own permissions say you can read its records. An administrator who has the module but a reader who cannot see contracts will not be offered the contract templates, because the workflow would write records that reader cannot open.
| Requirement | Feature gate | Permission | Templates it controls |
| - | - | - | - |
| Contracts | `contracts-page` | Read contracts | Every template on the Contracts shelf |
| Radar monitoring | `radar-page` | Read Radar alerts | Monitoring signal triage |
| Risk register | `risk-page` | Read risks | High inherent risk escalation |
| Screening | `sanctions-screening` | Read screening matches | Screening match adjudication |
| Obligations | `obligations-page` | Read obligations | Contract obligation ownership |
| Intake | none | Read intake sessions | Risk-tiered intake routing, Intake to onboarding assessment, Purchase request approval chain |
| Purchase requests | `procurement-demo` | none | Purchase request approval chain |
| Monitoring records | `monitoring-between-assessments` | Read vendors | Reassessment scoping from the monitoring record, Monitoring record turned not clean |
Intake is the one module with no gate of its own, so the read permission is the whole test. That matches the left-hand navigation, which shows the **Intake** item on the same rule. Purchase requests are the reverse: there is no separate read permission for them, so the gate is the whole test.
Two templates need two modules at once. Contract obligation ownership needs Contracts and Obligations, because the obligations it assigns come out of contract paperwork. Purchase request approval chain needs Intake and Purchase requests, because it turns a submitted request into a purchase request.
Eight templates require nothing beyond vendors, services, assessments, findings and tasks, and are visible in every workspace: New vendor onboarding, assessment to decision; Bank detail change verification; Two-level assessment sign-off; Zero-touch assessment launch; Evidence collection handoff; Finding remediation and vendor commitments; Vendor offboarding with sign-off; and Route work to the vendor's owner.
Two near misses are worth naming, because you might expect them to be gated and they are not.
* **Finding templates are not gated on the Findings module.** A finding raised inside an assessment is exempt from that gate, so findings exist, and the template works, in a workspace without the standalone Findings area.
* **Zero-touch assessment launch has nothing to do with the Zero Touch Assessments module.** It starts an ordinary assessment that collects no documents.
## How a chain moves
Most templates are chains: one step's decision opens the next stage, and a rejection sends the work back. Four rules hold every chain together, and each template's setup list repeats the ones that apply to it.
* **A review stage advances on Accept and Reject.** The next stage opens when a review is set to the built-in **Accept** status, and the rework or rejection step fires on **Reject**. A custom decision status you added yourself does neither.
* **Stages are told apart by review name.** Each step's gate matches the name of the review the stage before it opened. Rename a review and update the gates on the steps after it.
* **A step acts only on what its own workflow opened.** The **Opened by this workflow** condition (under **This workflow** in the condition picker) ignores a review or task opened by hand, or by another workflow, that happens to carry the same name. Keep it if you rework a step.
* **A handoff between people follows the task title.** Where the next step waits for a task to be completed, it recognizes the task by its title. A task renamed by hand stops the chain there.
## Every template in detail
Each entry below gives the trigger the template listens for, the records it writes and their default clocks, and the short list of things to change before you switch it on.
<Note>
Every title below is written the way the template writes it. `{vendor}` stands for the vendor's own name and `{contract}` for the contract's, both filled in when the workflow runs, so a real task reads "Kick off onboarding review for Northwind Analytics".
</Note>
### Risk-tiered intake routing
**Shelf:** Intake · **Needs:** Intake · **Steps:** 4 · **For:** intake owners and TPRM program leads
Sends each request down the path its inherent risk earns, so the review effort matches the exposure instead of one depth for all.
**What it does.** Three steps listen for a request being submitted, each gated on a band of the 0 to 100 inherent risk score. Up to **30**, the request gets an approval task instead of an assessment. From 30 to **70** it opens a standard assessment, and above 70 an enhanced one. A fourth step hangs off whichever assessment opened and raises the kickoff task.
**What lands in the queue.** For a low score, a task titled **"Approve low-risk request for `{vendor}`"**, filed as an intake request review, **due in 2 days**. Otherwise an assessment named **"Standard due diligence for `{vendor}`"** or **"Enhanced due diligence for `{vendor}`"**, plus a task titled **"Kick off due diligence for `{vendor}`"**, filed as an assessment review, **due in 3 days**.
**Before you turn it on.** Move the 30 and 70 breaks onto your own tier boundaries. Scores carry decimals, so start each band immediately above where the one below ends, or a score between them opens nothing. Point the standard and enhanced steps at your own assessment plans, or each opens an empty assessment. Re-point the approval task, the assessments and the kickoff task. The score is the one the intake's inherent risk questionnaire produced; an intake without one falls back to the vendor's current score, and with neither the request matches no band.
### Intake to onboarding assessment
**Shelf:** Intake · **Needs:** Intake · **Steps:** 2 · **For:** intake owners and assessment team leads
Turns an accepted request into a real assessment the same day it is submitted, with a kickoff task behind it. It closes the gap where a request is approved in principle and then waits a week for someone to open the review.
**What it does.** Two steps, chained. On submission it opens an assessment named **"Onboarding assessment for `{vendor}`"**. Creating that assessment raises its own event, and the second step hangs off that event rather than off the intake submission, so the kickoff task cannot be raised for an assessment that failed to open.
**What lands in the queue.** The assessment, plus a task titled **"Kick off onboarding review for `{vendor}`"**, filed as an assessment review, **due in 3 days**.
**Before you turn it on.** Point the assessment step at one of your assessment plans, or it opens an empty ad-hoc assessment that somebody then has to scope by hand. Re-point the assessment's creator, its assignee and the task. If only some requests should open an assessment, gate the trigger on an inherent-risk threshold, or use the risk-tiered routing template above, which does it for you.
### Purchase request approval chain
**Shelf:** Intake · **Needs:** Intake and Purchase requests · **Steps:** 6 · **For:** procurement, intake owners and approvers
Turns a submitted request into a purchase request and walks it through the business owner, then risk and security, then legal and commercial, each approval opening the next. A rejection at any stage goes back to the requester instead of stalling in a queue.
**What it does.** On submission it opens a purchase request titled **"Purchase request: `{vendor}`"**, and a review for the business owner. Accepting that review opens the risk and security review; accepting that opens the legal and commercial review.
**What lands in the queue.** The three reviews in turn, then, once the last is accepted, a task titled **"Place the order with `{vendor}`"**, filed as a procurement review, **due in 5 days**. A rejection at any stage raises **"Purchase request for `{vendor}` was declined"**, **due in 3 days**, asking the owner to tell the requester what would change the answer.
**Before you turn it on.** Re-point each review at the person or group who signs at that stage. They all land on you until you do, which defeats the chain. The chain rules in [How a chain moves](#how-a-chain-moves) apply.
### New vendor onboarding, assessment to decision
**Shelf:** Onboarding · **Needs:** nothing · **Steps:** 5 · **For:** TPRM program owners and assessment leads
Any vendor added to the portfolio, by intake, by import, or by hand, gets an assessment, a kickoff task and, once the assessment is complete, a recorded onboarding decision. Vendors that skip intake are the ones that usually go unassessed.
**What it does.** On vendor creation it opens **"Onboarding assessment for `{vendor}`"** and, off that assessment, a kickoff task. Separately, when any assessment reaches the Complete stage, it opens a review named **"Onboarding decision: `{vendor}`"**. Accepting that review raises the activation task; rejecting it raises the close-out task.
**What lands in the queue.** A task titled **"Kick off onboarding review for `{vendor}`"**, **due in 5 days**, then the decision review, then either **"Activate `{vendor}`"** or **"Close out declined vendor `{vendor}`"**, each **due in 3 days** and filed as an assessment review.
**Before you turn it on.** Point the assessment step at an assessment plan. Re-point the creator, the assignee, the decision review and both follow-up tasks; the decision usually belongs to the TPRM lead and the follow-up to the relationship owner. The decision opens for every assessment in the workspace that reaches Complete, so gate it on a plan if only onboarding assessments should ask for one. A bulk import of several hundred vendors raises an assessment for each: gate the first step on a risk threshold, or switch the workflow off for the duration of the migration.
<Frame>
<img alt="The detail pane for High inherent risk escalation, showing two steps and four setup notes" />
</Frame>
### High inherent risk escalation
**Shelf:** Risk triage · **Needs:** Risk register · **Steps:** 2 · **For:** risk analysts and the TPRM lead
Catches the vendor that was low risk at onboarding and is not any more. When the inherent risk score moves into the top band, it escalates for a senior look and opens a register entry so the exposure is tracked rather than noticed.
**What it does.** Two independent steps on the same trigger, both watching the vendor's `raw_irq_score` and inherent risk level. When either field changes and the resulting score sits between **70 and 100**, one step raises the escalation task and the other opens the register entry. They are independent rather than chained, so removing one leaves the other working.
**What lands in the queue.** A task titled **"High inherent risk: review `{vendor}`"**, filed as an assessment review, **due in 5 days**, with instructions to confirm the score change is real rather than a half-finished questionnaire, check the assessment scope still matches, and decide whether the relationship needs a senior owner. Alongside it, a risk register entry described as **"Elevated inherent risk on `{vendor}`"**, opened at **likelihood 3, impact 4**, with no risk domain set.
**Before you turn it on.** The 70 to 100 band is a starting line on the 0 to 100 score, not a standard, so move it to your own tier break. Re-point the task and the register entry's owner. Set the entry's risk domain so it rolls into the right appetite tolerance. Treat the 3 and the 4 as a placeholder for a human to correct, not a score.
**Worth knowing.** Both steps fire on every update that moves a watched field while the score is still in the band, so a vendor whose score walks from 72 to 78 to 81 collects a task and an entry each time. Narrow the gate, or drop the register step, if you want one per escalation.
### Bank detail change verification
**Shelf:** Risk triage · **Needs:** nothing · **Steps:** 2 · **For:** accounts payable, treasury and vendor managers
Payment-instruction fraud starts with an email and a plausible letterhead, and the next invoice pays someone else. This puts a verification step between the change and the payment run.
**What it does.** One step listens for a vendor's bank account being updated, and a second for a new account being added, since a second account is the other half of the same fraud.
**What lands in the queue.** A task titled **"Verify changed bank details for `{vendor}`"** or **"Verify new bank details for `{vendor}`"**, filed as an assessment review, **due in 2 days**, whose instructions carry the control itself: call the vendor on a number you already held rather than one from the request, confirm which account future invoices should pay, and record who confirmed it.
**Before you turn it on.** Re-point the task at whoever is allowed to approve a payment change. The control is worth nothing if it lands on the person who made the change. Two days is short because the window that matters is the one before your next payment run; match it to that run. A vendor's first account raises a task too, so drop the second step if you verify first accounts during onboarding instead.
### Screening match adjudication
**Shelf:** Risk triage · **Needs:** Screening · **Steps:** 2 · **For:** compliance analysts and the financial crime desk
A sanctions or adverse-media hit is only useful if somebody clears it or acts on it. This puts every new match on a desk with a clock, then has a second person check each decision, so no one clears their own match.
**What it does.** When screening raises a match it opens an adjudication task. When that task is completed, a second step raises the second-line check.
**What lands in the queue.** A task titled **"Adjudicate a screening match for `{vendor}`"**, **due in 3 days**, asking the analyst to compare the matched record against what you hold, decide between false positive, true match and needs-more-information, and record the reasoning. Then **"Check a screening decision for `{vendor}`"**, **due in 2 days**. Both are filed as assessment reviews.
**Before you turn it on.** Re-point the adjudication at the compliance desk that owns screening, which is rarely the TPRM queue, and point the second-line check at a different person. Three days is a starting clock; if you work to a regulatory deadline, set that instead. Every match raises a task, including the false positives, which are most of them, so gate the trigger once you know your own hit rate.
### Two-level assessment sign-off
**Shelf:** Assessments · **Needs:** nothing · **Steps:** 5 · **For:** assessment leads, QA reviewers and second-line risk
A maker-checker review for every assessment. Only a second-line approval completes the assessment, and the result is then handed to the business.
**What it does.** When an assessment reaches the Review results stage it opens **"First-line review: `{vendor}`"**. Accepting it opens **"Second-line review: `{vendor}`"**. A second-line rejection reopens the first line as **"First-line review (rework): `{vendor}`"**; a second-line acceptance completes the assessment. Once the assessment is complete, the last step raises the handoff.
**What lands in the queue.** The reviews in turn, then a task titled **"Assessment result for `{vendor}`"**, filed as an assessment review, **due in 3 days**, whose description links straight to the report.
**Before you turn it on.** Re-point the first-line and second-line reviews at different people or groups; two reviews by the same person is not a check. Re-point the handoff task at the person who asked for the assessment, usually the vendor's relationship owner. The chain starts for every assessment that reaches Review results, so gate that step on a plan if only some assessments need two levels. The chain rules in [How a chain moves](#how-a-chain-moves) apply.
### Zero-touch assessment launch
**Shelf:** Assessments · **Needs:** nothing · **Steps:** 2 · **For:** assessment team leads
Assessments that need nothing from the vendor should not wait in a queue for somebody to press Start.
**What it does.** On assessment creation, it checks the assessment's document collection mode. If the mode is **none**, it starts the assessment run immediately. If the assessment collects documents, manually or automatically, the step is rejected and nothing happens, so an assessment is never started behind the person who was about to collect its evidence. When such an assessment reaches Review results, the second step raises a review task.
**What lands in the queue.** A task titled **"Review the zero-touch result for `{vendor}`"**, filed as an assessment review, **due in 3 days**, linking the results.
**Before you turn it on.** Pair it with an assessment plan whose collection mode is **none**, or nothing will ever match: assessments default to manual collection, and a default workspace will see this workflow sit idle forever. Re-point the review task at whoever signs off automated results.
**Worth knowing.** Despite the name, this has no relationship to the Zero Touch Assessments module. It starts an ordinary assessment.
### Evidence collection handoff
**Shelf:** Assessments · **Needs:** nothing · **Steps:** 2 · **For:** assessment analysts and evidence coordinators
Automatic evidence collection gives up quietly. This catches the handoff and puts it on a named desk with a date, then hands the assessment back to its analyst once the documents are in.
**What it does.** Listens for the event Coverbase raises when automatic collection hands an assessment back to a human, and opens a collection task. When that task is completed, the second step raises the handback.
**What lands in the queue.** A task titled **"Collect evidence for `{vendor}`"**, filed as a document collection handoff so it sorts with the rest of the evidence work, **due in 5 days**. Then **"Resume the assessment for `{vendor}`"**, filed as an assessment review, **due in 3 days**.
**Before you turn it on.** Re-point the collection task to whoever chases vendors for documents, and the handback at the analyst who owns the assessment. Match the five-day clock to the evidence SLA you publish.
### Reassessment scoping from the monitoring record
**Shelf:** Assessments · **Needs:** Monitoring records · **Steps:** 2 · **For:** assessment leads and the analysts who plan reassessments
When a vendor's next assessment comes due, the monitoring record already says what happened since the last one. This hands that record to an analyst while there is still time to scope the reassessment on it.
**What it does.** Fires once per record, when the reassessment reminder goes out. A record that is **Not clean** or **Unmonitored** raises a scoping task; a **Clean** one raises a short task to confirm the lighter approach still fits. A record still pending its first verdict raises neither.
**What lands in the queue.** **"Scope the reassessment for `{vendor}`"** or **"Confirm the reassessment approach for `{vendor}`"**, filed as an assessment review, **due in 5 days**, linking the record.
**Before you turn it on.** Re-point both tasks at whoever scopes reassessments, usually the vendor's risk analyst. If the reminder leaves too little time to scope, move it earlier in your reassessment settings.
### Finding remediation and vendor commitments
**Shelf:** Remediation · **Needs:** nothing · **Steps:** 2 · **For:** findings owners and vendor relationship owners
A finding with no owner and no date tends to stay open until the next audit asks about it, and a vendor's promise to fix it is where tracking usually stops.
**What it does.** Two independent steps. One opens a dated remediation task for every new finding, whatever raised it. The other raises a chase task when a vendor commitment is recorded.
**What lands in the queue.** A task titled **"Remediate finding on `{vendor}`"**, **due in 30 days**, and a task titled **"Check the commitment from `{vendor}`"**, **due in 14 days**, both filed as assessment reviews.
**Before you turn it on.** Re-point both tasks: findings usually belong to the vendor's risk analyst, and chasing a commitment to whoever holds the relationship. Thirty days is one clock for every finding; if your policy varies by severity, duplicate the first step and gate each copy with a filter. Fourteen days on the commitment is a check-in, not the commitment's own deadline.
### Contract review, approval handoff and execution
**Shelf:** Contracts · **Needs:** Contracts · **Steps:** 5 · **For:** legal, security, procurement and contract owners
Every new contract is read by legal, then by security and privacy, before anyone is asked to approve it. Signature then raises the handover, so the obligations get owners while the negotiation is still fresh.
**What it does.** A new contract opens **"Legal review: `{contract}`"**. Accepting it opens **"Security and privacy review: `{contract}`"**, and accepting that raises the approval handoff. A rejection at either review raises the rework task. Separately, when the contract reaches **Executed**, the last step raises the handover.
**What lands in the queue.** The two reviews in turn, then **"Submit `{contract}` for approval"**, **due in 3 days**, or on a rejection **"Renegotiate `{contract}`"**, **due in 7 days**. On execution, **"Hand over `{contract}`"**, **due in 5 days**. All three tasks are filed as contract reviews and link the contract.
**Before you turn it on.** Re-point both reviews and the tasks. Value-based sign-off belongs to the contract approval policies in your settings, not to this workflow; the approval task only says the reviews are done. Imports create contracts too, so switch the workflow off during a bulk import, or gate the first step on value or type. The chain rules in [How a chain moves](#how-a-chain-moves) apply.
### Contract renewal runway and expiry
**Shelf:** Contracts · **Needs:** Contracts · **Steps:** 2 · **For:** procurement and vendor managers
Auto-renewal deadlines pass in silence and cost a year of spend. Whenever a renewal, expiry or notice date is set or changed, this raises a decision task with a month of runway on it, and if a term still runs out, a follow-up the day it expires.
**What it does.** One step watches four fields on a contract: `renewal_date`, `expiration_date`, `notice_due_to_vendor_date` and `auto_renew`. When any of them moves, it raises the decision task. The other fires when Coverbase's daily lifecycle job marks a contract expired, which is the day after its term ends.
**What lands in the queue.** A task titled **"Renewal decision: `{contract}`"**, **due in 30 days**, and on expiry **"`{contract}` has expired"**, **due in 7 days**, whose description warns that the service it covers is running uncontracted. Both are filed as contract reviews and link the contract.
**Before you turn it on.** Understand what triggers it: the first step fires when a date **moves**, not when one **approaches**. It is the workflow for "somebody told us the renewal is in March", not the countdown to March itself; pair it with [contract date reminders](/user-guides/contract-dates-and-reminders) for the countdown. Re-point both tasks to the contract's owner, and trim the watched date list to the ones your contracts carry. The expiry step fires on every expiry, including ones already replaced, so gate it if your renewals supersede rather than extend. A bulk import that brings contracts in already expired does not raise a task for each, because only the daily job marking a term expired fires it.
<Note>
The dates themselves are available as `{contract:renewal_date}` and `{contract:notice_due_date}` if you want them in the body, and the template leaves them out on purpose. A contract with that date still empty would stop the task being raised at all.
</Note>
<Frame>
<img alt="Searching the workflow template gallery for 'segregation', showing three templates from different shelves that carry the Segregation of duties label" />
</Frame>
### Contract obligation ownership
**Shelf:** Contracts · **Needs:** Contracts **and** Obligations · **Steps:** 2 · **For:** contract owners, compliance and control owners
An obligation extracted from a contract and left unassigned is a commitment the org has made and nobody has read. This puts an owner and a date behind each one as it is raised, then has that owner tie it to the control that satisfies it.
**What it does.** Fires when an obligation is raised against a vendor's document, which is usually when contract analysis finishes. When that task is completed, the second step raises the evidence task.
**What lands in the queue.** A task titled **"Assign a contract obligation for `{vendor}`"**, **due in 14 days**, then **"Evidence a contract obligation for `{vendor}`"**, **due in 30 days**, both filed as contract reviews.
**Before you turn it on.** Contract analysis raises obligations in batches, so a freshly analyzed contract can produce a dozen tasks at once. Run it on one contract before turning it on across the workspace. Re-point the first task at whoever triages obligations, and reassign the second to the control owner the triage named.
<Note>
An obligation typed in by hand with no source document has no vendor behind it, so no task is raised for it. The alternative would be a task filed against the wrong vendor.
</Note>
### Monitoring signal triage
**Shelf:** Monitoring · **Needs:** Radar monitoring · **Steps:** 2 · **For:** monitoring analysts and the TPRM lead
A monitoring program is only worth the alerts somebody reads. This turns each new signal into an adjudication record and a dated task, so the queue is worked rather than watched.
**What it does.** Two independent steps on signal creation. One opens a review named **"Signal review: `{signal}`"**, bound to the signal itself so the adjudication has a record from the start. The other raises the task that gives it a clock.
**What lands in the queue.** The review, plus a task titled **"Triage monitoring signal for `{vendor}`"**, filed as an assessment review, **due in 3 days**, carrying the signal's name and severity in its description.
**Before you turn it on.** Re-point both steps to whoever works the alert queue. Set the review's status so signals start in your adjudication pipeline. Every signal raising a task is a lot of tasks, so gate the trigger on severity once you know your own volume.
### Monitoring record turned not clean
**Shelf:** Monitoring · **Needs:** Monitoring records · **Steps:** 2 · **For:** monitoring analysts and relationship owners
A vendor that was clean at its last assessment has something on its record now. This puts the record in front of an analyst the day the verdict turns, and then has the business owner hear about it from you.
**What it does.** When a record's verdict turns **Not clean**, it raises a review task. When that task is completed, the second step raises the briefing task.
**What lands in the queue.** **"Review the monitoring record for `{vendor}`"**, then **"Brief the business on `{vendor}`"**, each filed as an assessment review and **due in 3 days**.
**Before you turn it on.** Re-point the review task at whoever works the monitoring queue, and the briefing at the vendor's relationship owner. If it fires too often, tighten what counts toward the verdict in the monitoring records policy rather than here.
### Vendor offboarding with sign-off
**Shelf:** Offboarding · **Needs:** nothing · **Steps:** 4 · **For:** TPRM program owners, security operations and legal
Archiving a vendor record is not offboarding it. This splits the exit into the three jobs different teams own, and raises a final sign-off only once every open task on the vendor is closed.
**What it does.** When a vendor record is archived, three steps raise the exit tasks in parallel. A fourth waits for the last open task on that vendor to be completed, then raises the sign-off.
**What lands in the queue.** **"Offboarding: revoke access for `{vendor}`"** (**due in 7 days**), **"Offboarding: confirm data return or destruction by `{vendor}`"** (**30 days**) and **"Offboarding: terminate contracts with `{vendor}`"** (**14 days**), then **"Sign off the exit of `{vendor}`"** (**5 days**), all filed as assessment reviews.
**Before you turn it on.** Re-point each exit task at the team that owns it: access to security operations, data to privacy, contracts to legal. The sign-off waits for every open task on the vendor, not only these three, so close or move anything unrelated. The exit tasks are recognized by their **Offboarding:** title prefix; keep it if you reword them, and keep it out of the sign-off's title.
### Route work to the vendor's owner
**Shelf:** Routing · **Needs:** nothing · **Steps:** 2 · **For:** TPRM program owners running a shared queue
Work that lands on a central desk gets triaged twice: once to work out whose vendor it is, and once to do the thing. This template removes the first pass.
**What it does.** When any task is raised, it re-points the assignee onto the relationship owner recorded against that task's vendor, so the queue arrives sorted. When a vendor is created with no relationship owner, a second step raises a task asking for one.
**What lands in the queue.** No new record for the routing itself; it changes who an existing task belongs to. For an ownerless new vendor, a task titled **"Name an owner for `{vendor}`"**, **due in 5 days**.
**Before you turn it on.** Understand its reach: this moves the assignee on every task the workspace raises, not only the ones a workflow raised. Gate the trigger on task type if you only want it for some of them. Fill in the owners of the vendors you already hold before turning it on. Vendors created by a process that names the owner afterwards, such as a bulk import, raise the ownership task anyway; close those by hand or turn the second step off during the import.
**Who it routes to.** The vendor's first relationship owner, which can be a person **or a group**, so this is how a template routes to a team without naming one. Swap the step to risk analysts if that is who owns your queue.
<Note>
A vendor with no relationship owner is left alone. The task keeps the assignee it already had rather than being unassigned.
</Note>
## Applying one
Selecting a card shows what the template does, step by step, as **when** something happens / **if** these conditions hold / **then** this is written. Underneath it is the list of things to change once it lands.
**Use template** copies it into your workspace and opens it in the editor, switched off.
<Frame>
<img alt="New vendor onboarding, assessment to decision open in the Coverbase workflow editor, with five steps in two connected groups and the Enabled toggle off" />
</Frame>
It is now an ordinary workflow, and it appears in the list alongside the ones you built by hand.
<Frame>
<img alt="The Coverbase workflows list searched for 'onboarding', showing the applied template beside a hand-built workflow" />
</Frame>
## The two things every template leaves for you
### Who the work goes to
A task with nobody on it does nothing, and a template cannot know your people, so **every task, review, assessment and register entry a template creates is assigned to whoever applied it.** This means the workflow runs as soon as you switch it on, rather than skipping. It is also the first thing to change on almost every template. Open the step, change the assignee to the person, department or role that should own the work, and save.
### What is org-specific
Templates never reference anything that belongs to one workspace (a status, a tag, an assessment plan, a questionnaire, an email template) because a template holding one would apply everywhere and run nowhere. That is why an assessment step opens an ad-hoc assessment until you point it at a plan, and why a review starts at its default status until you set one.
Both are listed under **Change these before you turn it on**, in the order to work through them.
## Making one your own
A template is a starting point. Once it is in your workspace:
* **Narrow the trigger.** Most templates ship wide: every vendor, every finding, every signal. Adding a condition (an inherent-risk threshold, a tag, a filter on the record) is usually the difference between a useful queue and a noisy one.
* **Split a step in two.** A thirty-day remediation clock for every finding becomes two steps with different clocks once you gate each one on severity.
* **Add a step.** Templates stop at what is portable; yours can send an email from one of your templates, [post to a webhook](/user-guides/webhooks), or [open a ServiceNow record](/user-guides/servicenow-workflow-actions).
* **Rename everything.** Step names, workflow name, the copy inside the tasks. All of it is yours, and the task instructions especially are written to be edited.
* **Apply the same template twice.** Two copies with different gates, one for critical vendors and one for the rest, is a normal way to use the library.
<Tip>
Run a new workflow against a small slice first. Add a gate that matches one tag or one department, watch the tasks it raises for a week, then widen it.
</Tip>
## Where to go next
<CardGroup>
<Card title="Assignment and delegation" icon="user-check" href="/user-guides/assignment-and-delegation">
Who owns what, and the departments and roles a workflow step can route to instead of a person.
</Card>
<Card title="Reviews and approvals" icon="circle-check" href="/user-guides/reviews-and-approvals">
The review records the contract and monitoring templates open, and the pipelines they move through.
</Card>
<Card title="Contract dates and reminders" icon="calendar-days" href="/user-guides/contract-dates-and-reminders">
The countdown to a renewal, as opposed to the decision task the renewal template raises when a date moves.
</Card>
<Card title="Zero touch assessments" icon="bolt" href="/user-guides/zero-touch-assessments">
The assessments that need nothing from the vendor, which the zero-touch template starts automatically.
</Card>
</CardGroup>
# Zero Touch Assessment guide
Source: https://docs.coverbase.com/user-guides/zero-touch-assessments
How to run a lightweight, no-outreach assessment across a portfolio of vendors, read the score it produces, and decide which vendors are worth a full review.
<div>For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>
<Info>
This guide is part of the [User Guides](/user-guides/overview) collection. For what the capability is and where it stops, see [Zero Touch Assessments](/products/zero-touch-assessments). For the sub-scores it folds in, see [Financial Health Score](/products/financial-health-score), [Security Intelligence](/products/security-intelligence), [Corporate Registrations](/products/corporate-registrations) and [People Intelligence](/products/people-intelligence).
</Info>
<Note>
Zero Touch Assessments are an optional module. If you do not see **Zero Touch** in the left navigation, ask your Coverbase representative to turn it on.
</Note>
A Zero Touch Assessment answers one question cheaply: **is anything obviously wrong with this vendor?**
It is an ordinary assessment on the ordinary pipeline, with the same controls, issues and evidence. Three differences make it a triage tool rather than a review:
<CardGroup>
<Card title="Nobody is contacted" icon="envelope-open">
No document request, no questionnaire, no waiting on a vendor to reply. A run completes against public research and whatever evidence is already on file.
</Card>
<Card title="It runs without you" icon="wand-magic-sparkles">
Launch it across a batch and walk away. Nothing is assigned to a reviewer and nothing waits on a reply, so covering a long tail of vendors takes no ongoing effort.
</Card>
<Card title="It produces one number" icon="gauge">
A single Zero Touch Score, so a batch of vendors can be ranked rather than read one by one.
</Card>
</CardGroup>
## When to reach for one
Zero Touch is a **filter**, not a replacement for a full assessment. It is the right tool when:
* A new vendor arrives and you need to know whether to spend a real review on it.
* You have inherited a portfolio and have no idea which vendors are risky.
* A renewal is coming up and you want a cheap re-check since the last review.
* Someone asks "are we exposed to this vendor?" and you need an answer today.
It is the **wrong** tool when you need assurance you can show an auditor. A run has never spoken to the vendor, so it cannot confirm a control is operating. It can only tell you whether public evidence supports it.
## Running one
<Frame>
<img alt="The Zero Touch launch wizard, showing vendor selection with a search box and a running count of selected vendors." />
</Frame>
<Steps>
<Step title="Pick your vendors">
On the **Zero Touch** page, click **Launch zero-touch assessment** and choose one vendor or many. You can also start from a vendor's own page, or select rows in the vendors table and launch the whole selection at once.
</Step>
<Step title="Choose the question set">
Pick the template the run evaluates. **Zero Touch Comprehensive** is the default and covers everything public evidence can settle; the lighter and industry-specific templates are there when that is more than you need.
<Warning>
Choosing a template changes what **every future run** evaluates, not only this one. It is an organization-level setting, reachable from the wizard. Your earlier runs keep the scope they were launched with, and each run records which template it used.
</Warning>
If your organization has documents evidence turned on, this step also offers **Use existing documents in each Zero Touch assessment**. Every document on file for each vendor is used by default. To narrow that, click the count beside the option to open **Choose Documents**: untick a vendor to run it without documents, or open the vendor and untick single documents. Each run is judged only on the documents left ticked.
</Step>
<Step title="Confirm">
The last step has no inputs. What feeds the score and where the score goes are configured once for your organization, so every run stays comparable with every other run on the same template.
</Step>
<Step title="Come back to the runs table">
Runs complete on their own. The module page sorts by score by default, which is the order to work them in.
</Step>
</Steps>
<Frame>
<img alt="The confirm step of the Zero Touch launch wizard, listing the vendors about to be assessed and the control sets in scope." />
</Frame>
<Frame>
<img alt="The Zero Touch runs table, listing vendors by composite score with per-component columns for controls, financial health, security, registration and people." />
</Frame>
This is the same table as the vendors and assessments lists, so everything you already know about those works here. Sort by any column, filter on any field, choose which columns to show and in what order, and save the whole arrangement as a view you can come back to or share with your team. Sorting by score is only the default; sort by when a run happened to watch a batch finish.
Two details specific to scoring:
* **Score columns read down, not across.** Every score sits in the same place in every row, so you can scan a column rather than read each row.
* **A dash is not a zero.** It means the component did not resolve for that vendor, and it was left out of the composite rather than counted against them.
* **Not scored** means no component resolved. The report lists the reason for each component: public evidence scored no control, the run found no data, your settings turn the component off, or the launcher left it out of the run. To get a score, add evidence (for example, the vendor's financial statements) and run the assessment again.
### Working a batch
Select rows with the checkboxes, then act on the whole selection at once. Click a checkbox to toggle that row. Hold **Shift** and click another to take everything in between.
<Frame>
<img alt="The Zero Touch runs table with three rows selected, and a floating bar reading 3 assessments selected with Approve, Escalate and Archive buttons." />
</Frame>
<Steps>
<Step title="Approve">
Records your approval against every selected run. Each one gets its own entry in its own audit trail, exactly as if you had opened it and approved it there.
</Step>
<Step title="Escalate">
Flags the selection for a full assessment. Escalating does not start one. Starting a full assessment is a separate step, because it commits your team and the vendor to work.
</Step>
<Step title="Archive">
Removes the selected runs from the module. This one asks for confirmation, because it is the only action here you cannot undo from this page.
</Step>
</Steps>
If a run in your selection has been archived by someone else since the page loaded, it is reported as skipped and the rest still go through.
## Reading a result
Open any run to read it as a report. The summary comes first: who the vendor
is, the composite and the five components it is made of, the spread of control
outcomes, and three short lists of what is in good shape, the key gaps, and the
checks still open. The evidence follows, and every control the run evaluated
sits in an appendix at the end. Use the rail on the left to jump straight to a
section.
<Frame>
<img alt="The top of a Zero Touch report for Northwind Analytics: headquarters and a High suggested tier, a composite score of 65 at Level 2 beside component scores for controls, financial, security, registration and people, a control outcomes bar, and three lists headed What's in good shape, Key gaps and Checks still open." />
</Frame>
A section that produced nothing says so in place. That is not a failing grade;
it means nothing public settled it, and its share of the score moved to the
sections that did report.
<Frame>
<img alt="A full Zero Touch report: the summary, why a high tier, reputation by axis, corporate registration with a ruled out name match, people, security posture, financial health, control results by area, issues raised, what to ask the vendor for, an appendix of every control with two control sets scored 92 and 78, the sources grouped by kind, and the Revisions, Activity and Notes panels." />
</Frame>
Read it in this order:
<Steps>
<Step title="Who the vendor is">
The page opens with the company itself: what it sells, the industry it operates in, what an organization would typically use it for, its services and where it is headquartered. This is for the common case where you know a vendor is in use but not what it does.
Everything here is researched from public sources, never asked of the vendor. Two separate confidence markers sit beside it, and they mean different things:
* **Identity confidence**: how sure the run is that it profiled the *right* company. Low when the name is generic or several companies share it.
* **Risk tier confidence**: how sure it is about the *exposure*. A run can be certain which company this is and still be unsure how much risk it represents.
</Step>
<Step title="The risk tier">
A triage read of how much exposure the vendor typically creates (critical, high, moderate, low or minimal) with a one-line reason and the full argument underneath.
<Note>
This is its own scale, not your organization's risk levels. Those are calibrated against a completed questionnaire; this is judged from the outside. It does not touch a vendor's inherent risk unless your organization turns that on, and even then it stands down if the composite score is already being written there.
</Note>
</Step>
<Step title="What turned up against the vendor's name">
**Reputation** follows the risk tier. It gathers everything the run found said about the vendor into one place: adverse media on its leadership, open watchlist matches if your organization screens, and the reputation controls the run evaluated. See [Reading the reputational section](#reading-the-reputational-section) below.
</Step>
<Step title="The composite, then what it is made of">
The headline number combines up to five independently-sourced components: the control evaluation, the vendor's Financial Health Score, its outside-in security rating, its corporate registration standing, and its leadership dossier. Each is scored 0-100 on its own before anything is combined.
</Step>
<Step title="Check which components resolved">
**A component with no data is left out, never counted as zero.** A vendor with no filed financials has not failed the financial component. It has no financial component, and the remaining weights are redistributed across what did resolve. The card tells you both the weight it was configured with and the share it carried.
<Warning>
This is the most common misreading. A vendor scoring 78 on one component is not comparable to a vendor scoring 78 on three. Check the composition before ranking two vendors against each other.
</Warning>
</Step>
<Step title="Work the controls">
**Control Results by Area** shows how each area of the control sets fared, and **Issues Raised** lists the open issues, most material first. Every control, with what it found and where, is in the **Appendix**. See [Working the controls](#working-the-controls) below.
</Step>
<Step title="Work the issues">
Each open issue carries the evidence behind it and the control set that raised it. This is the part that tells you *what* is wrong, as opposed to *how much*.
</Step>
<Step title="Check the sources">
Every place the run drew evidence from is listed, grouped by kind: web research, registries and filings, vendor infrastructure, and documents already on file. If a conclusion looks wrong, this is where you check its provenance.
</Step>
</Steps>
## Reading the reputational section
Reputational evidence arrives from three places, and the **Reputation** section puts all
three in one place so you do not have to go looking:
| Source | What it contributes |
| - | - |
| Adverse media | Negative news tied to the company or a named executive, from the vendor's leadership dossier |
| Watchlist screening | Open sanctions, PEP, criminal and legal matches, if your organization has [screening](/products/people-intelligence) turned on |
| Reputation controls | The `ZT-REP-*` controls the run evaluated itself: breach history, regulatory action, sanctions, adverse media, litigation and customer sentiment |
The section opens with an overall standing, then reports five dimensions, each with
its own standing:
* **Media and customer sentiment**: controversy in the press, breach coverage, what customers say publicly.
* **Litigation exposure**: suits naming the company or its principals.
* **Regulatory and enforcement**: regulator decisions, enforcement action, insolvency proceedings.
* **Executive conduct and stability**: matters attached to a named individual, and leadership churn.
* **Sanctions and association**: watchlist and financial-crime adjacency.
### Not screened is not clear
Each dimension reads one of four ways. The distinction that matters most is the last
two, because they look similar and mean opposite things:
| Standing | What it means |
| - | - |
| Adverse findings | A material matter was found. Read it. |
| Watch | Something was found, but nothing material: low severity, informational, disputed, or a matter the subject was cleared of. |
| Clear | Something searched this dimension and found nothing. |
| Not screened | Nothing searched this dimension. It says nothing about the vendor. |
<Warning>
**Not screened** is never evidence of a clean record. A dimension reads that way when
the template you ran carries no control for it, the vendor has no leadership dossier
yet, or your organization does not screen the relevant watchlist feed. The section
lists every unscreened dimension under the standing, so a short findings list is
never mistaken for a clean vendor.
</Warning>
### Material versus carried
A finding is **material** when it counts against the vendor. A matter the subject was
cleared of, or one a reviewer has already dispositioned, is still listed, because it
is part of the record of what the run read. It is not counted as material, and it does
not deduct from the score.
The findings list is ordered material first, then by severity, so the row you need is
at the top.
## Working the controls
Every control the run evaluated is listed in the report's **Appendix**, grouped into sections (Security, Privacy, Company and identity, and so on) with its identifier, the question that was put to the research, the answer, and the evidence behind it.
### The four outcomes
A Zero Touch run reads public evidence and nothing else, so pass/fail is not enough to describe the result. Each control lands in one of four states:
| Outcome | What it means |
| - | - |
| **Compliant** | Public evidence was found, and it meets the expectation. |
| **Partially compliant** | Evidence was found, but it is thin or indirect enough that the run is not certain. |
| **Issue** | Evidence was found, and it does not meet the expectation. |
| **Not settled** | Nothing public settles it. |
These four words are the only vocabulary the page uses for a control's state: the badge on the row, the view that lists it, and the compliance band over the whole set all say it the same way. A control whose question does not apply to this vendor reads **Not applicable**; it is listed with the unsettled controls and left out of its area's total.
<Warning>
**Not settled is not a finding against the vendor.** It says the question cannot be answered from outside, which is what a full assessment is for. Treating it as a failure is the most common way to misread one of these runs, which is why it has its own view rather than being folded in with the issues.
</Warning>
### Four views over the same list
* **With issues**: the controls the evidence contradicts. Start here.
* **Compliant**: compliant and partially compliant together, so you can see what the vendor demonstrably does publish.
* **Not settled**: the controls nothing public answered.
* **All controls**: everything, in section order.
### Recording your verdict
A control carrying an issue shows its decisions on the row. A control that came back compliant or unsettled folds the same decisions behind **Actions**.
<Steps>
<Step title="Confirm">
You agree with what the run concluded. The control stays as it is.
</Step>
<Step title="Dismiss">
You disagree, or the issue does not apply to how you use this vendor. The control is marked resolved and drops out of the open issues.
</Step>
<Step title="Add note">
Leave context for whoever reads the run next: why you accepted a thin answer, or what you checked separately.
</Step>
<Step title="Create findings">
Raise findings from a control. This is the same finding creation the assessment page uses, so the result is an ordinary finding that behaves like any other.
</Step>
</Steps>
To decide several at once, tick their checkboxes: the selection bar appears at the foot of the page with the same Confirm, Dismiss and Create findings actions, exactly as it does on the other lists in the product. Changing view clears the selection, so a bulk decision only ever lands on controls you could see.
Verdicts are recorded on the control itself, not in a Zero Touch-only place, so the assessment page and the Excel export show the same thing you decided here.
Once a result has been revised, by an analyst or by the automated review, its control outcomes come from the revised version and the verdict actions are hidden. To change an outcome after that, revise the assessment again. See [Revising a result](#revising-a-result).
### What is in a template
Every template card carries a **What does this control set assess for?** link listing all of its controls by section: the identifier, the question, and what the run treats as a pass. Read it before you commit a portfolio to a template.
## Revising a result
A run can only read what is public, so it will sometimes miss something you
know: the registry match is a different company, a vulnerability belongs to
another product with the same name, or the vendor sent you the policy the run
could not find. **Revise assessment** updates the result from text you paste,
without rerunning it.
<Steps>
<Step title="Paste what you know">
Open **Actions** > **Revise assessment** and paste analyst notes, evidence the vendor supplied, or a plain correction.
<Frame>
<img alt="The Revise assessment dialog with an empty text box, an example correction as placeholder text, a note that text is read as evidence rather than instructions, and Cancel and Propose changes buttons." />
</Frame>
</Step>
<Step title="Review each proposed change">
**Propose changes** reads the text against the result and lists every change it supports, grouped by section. Each one shows the old value, the new one, why, how confident it is, and the words from your text it rests on. Untick any you do not want. The score preview on the right recomputes from the changes you keep.
<Frame>
<img alt="The Revise assessment review step: seven of seven changes accepted, including a registry match unbound, a legal entity added, a sanctions rerun that follows from the unbound match, a vulnerability dismissed and a control moved from Issue to Partially compliant, beside a score preview taking the composite from 65 to 75." />
</Frame>
</Step>
<Step title="Apply">
Applying saves the result as a new version. Every value you changed is marked **Analyst revised** in the report and in the PDF export.
</Step>
</Steps>
Your text is read as evidence, not as instructions. A control only becomes
compliant when your text or a source already on the run supports its
requirement, and anything in the text that reads as an instruction to the
product is set aside and listed as ignored.
Some changes leave research resting on the old answer. Unbinding a registry
match, for example, means sanctions were screened against the wrong company.
Those appear as a **Rerun** that follows from the change above, and after
applying you can rerun that research and then reassess to carry your revision
onto it.
### Going back to an earlier version
**Revisions**, near the end of the report, lists every version of the result:
what produced it (the original run, an analyst revision, a restore or a
rescore), its composite, and the changes it applied. Open one to read it, and
**Restore** to make it current again. A restore is itself a new version, so
nothing in between is lost.
### The automated review
When **Check each finished run against the vendor's own pages** is on, every finished run is read a second time. The review reads the vendor's own website: its home page and the pages it links to, its trust and security pages, its policies, and pages found by a web search limited to the vendor's site. It applies only the corrections a quote from one of those pages, or from a public record already on the run, supports.
The corrections are saved as a new version, labeled **Automated review** under **Revisions**, with the quotes it relied on. Read it like any other revision, and **Restore** the previous version if you disagree. A result you revised while the review was running is left alone.
The setting is on by default. Turn it off under **Scoring** on the module page. A run you complete by hand, and a rescore, are not reviewed.
## Deciding what happens next
A result page is a decision point, and there are three reasonable exits:
<CardGroup>
<Card title="Accept it" icon="check">
The vendor is low-risk enough that a full review is not warranted right now. The score can be written onto the vendor's risk score automatically. See below.
</Card>
<Card title="Escalate" icon="arrow-up-right-from-square">
**Create full assessment** carries the vendor straight into a normal assessment, with the triage findings already on the record.
</Card>
<Card title="Reassess" icon="rotate">
Financial and security inputs refresh on their own schedule. **Reassess** recomputes the composite against today's data without re-running the controls, and takes a correction first if you give one.
</Card>
</CardGroup>
A fourth exit, **Archive**, takes a run out of the working set without deleting it, for a duplicate or a vendor you no longer use. It is confirmed before it applies, because it is the one action here you cannot undo from the page.
## Reviewing a run
Everything you can do to a run sits behind **Actions**, at the top right of the result page. You can **approve** the run, **create a full assessment** from it, **reassess** it, **revise** it from notes or evidence, open the full record, export it, or **archive** it.
<Frame>
<img alt="The Zero Touch Actions menu on a finished run: view full record, approve, create full assessment, reassess, revise assessment, export PDF, export spreadsheet, and archive." />
</Frame>
**Approve** opens a short dialog. Under **Vendor Disposition** you can also move the vendor to one of your organization's final statuses, or leave **Keep current status, record no disposition** selected, and add a note that prints beside the disposition in the report.
**Reassess** opens a box for a correction before it re-runs. Leave it empty and the run is re-scored against the sources already gathered.
The correction box takes plain language, not a form:
> *This is the wrong company. The vendor we mean is at northwind.example*
Zero Touch researches a vendor from public sources with nobody to ask, so it sometimes binds the wrong website, or a different company with a similar name. Describing that in a sentence is faster than finding the field it maps to.
**What happens when you submit:** the correction is read into a short, fixed set of fields, the website and the company name and nothing else. Those are applied to the vendor record, and the run is re-scored against them. Your exact words, the fields that changed, and the score before and after are all written to the audit trail below.
<Note>
A correction that could not be turned into a concrete change is still recorded, and the entry says so.
</Note>
### While a run is working
Results fill in as they land, so a run is readable long before it finishes. Each stage carries its own state, and the banner at the top is the only place a run can be stopped.
<Frame>
<img alt="A Zero Touch report for a run still working: a Running banner with a progress bar and its Cancel menu open on Cancel assessment and Start over, and every section below showing what it is still working on." />
</Frame>
The **Actions** menu keeps its shape while the run works and grays out what cannot work yet: there is nothing to export, no score to reassess and nothing settled to approve.
<Frame>
<img alt="The Zero Touch Actions menu on a run in flight, with approve, create full assessment, reassess, revise assessment and the exports grayed out, and view full record and archive still available." />
</Frame>
### Where a run stands
Every run carries a review status, shown on the result page and as a column in the runs table:
| Status | Meaning |
| - | - |
| **Running** | The engine is still working. The progress bar shows how far along it is. |
| **Review results** | Finished and scored, and nobody has decided on it yet. |
| **Approved** | A reviewer accepted the result. |
| **Escalated** | A reviewer judged that triage was not enough. |
| **Archived** | Out of the working set. Still readable by URL, and its trail is kept. |
| **Failed** | The run stopped before it could score, or was canceled. Launch it again to retry. |
A run is scored as soon as the engine finishes, before anyone approves it. Approval is a judgement about the result, not what produces it.
<Note>
Archiving does not overwrite an approval. The status answers "was this result accepted?"; archiving answers "is this still in my working set". They are different questions, and the trail records both.
</Note>
### The audit trail and notes
Below the result, the **Activity** section is the same activity log that vendors and assessments use, and it lists every action on the run with who took it, what it changed and what the score did: approvals, escalations, archives, corrections, re-scores and control verdicts alike. **Notes** sits underneath it for context that is not an action.
<Warning>
The Zero Touch review trail is **append-only**. Nothing on it can be edited or removed, including by us. A correction that later turns out to be wrong is fixed by making another correction, which appears as a new entry.
</Warning>
This matters because a Zero Touch Score can be written onto a vendor's real risk score. If a number moved, the trail is what tells you whether the machine found something or a person corrected it.
Escalating does **not** itself launch a full assessment. It records the judgement. Starting the assessment is a separate step, because it puts work in front of your team and your vendor.
## Where the score goes
By default the Zero Touch Score stays on the run. Your administrator can point it at a risk score instead, from **Scoring** on the module page:
| Setting | Effect |
| - | - |
| **Do not apply the score anywhere** | The score stays on the run and changes nothing else. |
| **Vendor inherent risk score** / **Vendor residual risk score** | Written onto the vendor's risk score when a run completes. |
| **Service inherent risk score** / **Service residual risk score** | Written onto each service the run covered. |
Only the axis you choose is written, so a Zero Touch run can never overwrite an inherent score your team set from an intake questionnaire.
<Note>
A vendor-scoped run configured to write a *service* score writes nothing, and says so on the result. Guessing which service was meant would move the wrong number.
</Note>
## Tuning what feeds the score
Also under **Scoring**: which signals count, and how heavily.
* Toggle the financial health, security, corporate registration and people components on or off for your organization.
* Set relative weights. They are not percentages. They are renormalised over whichever components resolve for a given vendor, which is why a vendor missing one component still scores out of a full 100.
Two of the components are derived rather than read from an existing score, and behave differently:
<AccordionGroup>
<Accordion title="Corporate registration">
Scores the registry standing of an identity that was matched to this vendor. A vendor no register matched is **unavailable**, not zero. Plenty of legitimate private companies appear in none of the free registers. A plausible but unconfirmed match is capped well below a confirmed one. A dissolved company scores above an unfound one, because being on record and wound up is better evidenced than never being found.
</Accordion>
<Accordion title="People">
Starts from how much of the leadership is on record and deducts for adverse-media findings, capped so a long tail cannot dominate a triage number. Informational items such as a departure or a disputed report are shown, and carry no weight.
**If adverse-media screening never ran, nothing is deducted at all.** A screening that did not happen cannot establish the clean record a zero deduction would imply, so the component scores leadership visibility alone and labels itself *Adverse media not screened*.
</Accordion>
</AccordionGroup>
## Choosing a template
Under **Scoring**, or as a step in the launch wizard, you can switch which set of questions Zero Touch runs evaluate. Seven ship with the product:
| Template | Questions | Best for |
| - | - | - |
| **Zero Touch Comprehensive** *(default)* | 49 | Everything public evidence can settle, across every domain |
| **Zero Touch Essentials** | 12 | Triaging a long tail fast, when you mostly need to know who to look at |
| **Zero Touch for SaaS and Cloud** | 30 | Vendors that host or process your data |
| **Zero Touch for Healthcare** | 21 | Vendors that may touch PHI |
| **Zero Touch for Financial Services** | 29 | Regulated financial-sector supply chains |
| **Zero Touch for Services and Suppliers** | 25 | Professional services, staffing and physical suppliers |
| **Zero Touch for Open Source Software** | 24 | An open-source project, library or self-hosted product you adopt rather than buy |
The first six draw on the same catalog of 49 questions about a company, spread across eleven domains: company and identity, security, privacy, compliance, technical operations, resilience, financial health, ethics, ESG, reputation and AI governance. A template is a selection from that catalog, not a separate set of questions, so a control means the same thing and is scored the same way whichever template you run. The open-source template asks its questions of a project instead of a company, and borrows only the sanctions and adverse media questions from the company catalog.
A question earns its place in the catalog only if public evidence can settle it. Anything that needs the vendor to answer would come back unevaluated on every run and make the vendor look worse than they are.
### What each one is for
<AccordionGroup>
<Accordion title="Zero Touch Comprehensive: 49 questions (the default)">
Every question in the catalog. This is the widest picture open-source research can produce, and the right starting point when you do not yet know what your portfolio looks like.
It is also the most sensitive to a thin vendor. A small supplier with no certifications, no filings and no security page will leave a lot of questions unevaluated, and the score reflects what could be checked rather than everything asked. If most of your tail looks like that, one of the narrower templates will read better.
</Accordion>
<Accordion title="Zero Touch Essentials: 12 questions">
The twelve questions that most often decide whether a vendor needs a full review: is this a real, standing company, is there any security posture on record, has anything gone publicly wrong, and is anyone accountable.
Fastest to run and cheapest to read. Use it when the goal is to sort a long list into "look at this" and "leave it", rather than to characterize any one vendor in depth. It is the best choice for a first pass over hundreds of vendors.
</Accordion>
<Accordion title="Zero Touch for SaaS and Cloud: 30 questions">
Weighted towards what matters when the vendor holds your data: SOC 2 and ISO 27001, sub-processor disclosure, hosting and region, encryption and TLS, MFA and SSO, vulnerability disclosure, status and incident history, exit and portability, and whether customer data is used to train models.
Drops most of the physical-supply and labour questions, which rarely apply and would otherwise sit unevaluated.
</Accordion>
<Accordion title="Zero Touch for Healthcare: 21 questions">
For vendors that may touch PHI. Adds weight to breach history, data retention and regulatory action, because healthcare enforcement is unusually well documented in public sources. HHS breach reporting in particular means a real incident is usually findable.
Narrower than the SaaS template on infrastructure detail, deeper on what happens to records and what regulators have said.
</Accordion>
<Accordion title="Zero Touch for Financial Services: 29 questions">
For regulated financial-sector supply chains. Emphasises operational resilience, regulatory standing, sanctions exposure and corporate transparency: who ultimately owns this company, and is that ownership traceable in a register.
This is the template most likely to surface a corporate-structure problem, which is often the finding that matters in a financial supply chain.
</Accordion>
<Accordion title="Zero Touch for Services and Suppliers: 25 questions">
For professional services, staffing and physical suppliers, where the technical surface is small and the real questions are ethics, labour practices, continuity and financial standing.
Use this rather than Comprehensive for vendors with little or no online product. Asking a staffing agency about sub-processors and TLS configuration produces a page of unevaluated controls and a score that says more about the questions than the vendor.
</Accordion>
<Accordion title="Zero Touch for Open Source Software: 24 questions">
For open-source software your organization adopts rather than buys as a service. It asks what the license obliges you to do, who maintains and funds the project, how releases are verified and vulnerabilities handled, and what the software sends out of your environment.
Launch it on a record for the project itself: name the record after the project and use its home page or source repository as the website. Run against a company record, it fails the project identity question and leaves the other project questions unevaluated.
</Accordion>
</AccordionGroup>
<Note>
If a lot of your runs come back with many unevaluated controls, that is usually a sign the template is wrong for the kind of vendor rather than a sign the vendor is bad. Switch to a narrower template and re-run.
</Note>
<Warning>
Switching template applies to future runs. Past runs keep the scope they were launched with, and each run records which template it used, so if you compare two runs, check they answered the same questions.
</Warning>
If your organization runs a control set of its own rather than one of these, no template is highlighted and the picker says so.
## Getting the results out
<Steps>
<Step title="A whole portfolio">
Select runs in the table and choose **Export as Excel** from the selection bar. One row per run, carrying the score, band, the reputational standing and its material finding count, and the profile fields including the risk tier and its reasoning. **Export PDF** on the same bar gives a portfolio report of the selected runs, with the score each reached and where it stands in review.
</Step>
<Step title="A single run">
From **Actions** on a result page, **Export spreadsheet** gives a summary sheet, a **Reputational Risk** sheet, a **Notes** sheet when the run has notes, and sheets for the score components, control-set coverage, every control, the issues raised and the sources cited, plus one sheet per intelligence surface the vendor has. **Export PDF** gives a letter-sized report laid out like the page itself. It opens the same export dialog Vendor Intelligence uses. The cover always prints; untick any other section to leave it out. Under **Vendor Intelligence Detail Pages** you can also add the full corporate registrations, people, security posture and financial health pages for the surfaces this run covered, and they print after the report in the same file.
</Step>
<Step title="Finding the reputational read quickly">
In the spreadsheet it is in two places: on the summary sheet under the score, one line per dimension, and on the **Reputational Risk** sheet, which is the second tab and carries one row per finding with its publisher, date and link. In the PDF it follows the summary and the risk tier reasoning, in the same order as the page.
</Step>
</Steps>
## Things worth knowing
<AccordionGroup>
<Accordion title="Why is my runs table empty right after a bulk launch?">
It should not be. In-flight runs appear immediately and sort below scored ones. If it is genuinely empty, no Zero Touch runs exist yet for this organization.
</Accordion>
<Accordion title="Do Zero Touch runs show up in my normal assessments list?">
Yes. A Zero Touch run *is* an assessment. The vendor's **Assessments** tab splits into **Full Assessments** and **Zero Touch Assessments**, and the full list excludes triage runs so a first pass is never mistaken for a completed review. The Zero Touch list shows the vendor's runs by date, each with how many controls it evaluated and how many issues it found, and offers **Start full assessment** when you hover a run.
</Accordion>
<Accordion title="A reputational dimension says Not screened. Is the vendor clean?">
No. **Not screened** means nothing looked at that dimension, so it carries no information about the vendor at all. **Clear** means something searched and found nothing. Switching to a template that carries the missing control, or turning on the watchlist feed for that dimension, is what changes it.
</Accordion>
<Accordion title="Why did a control come back unevaluated?">
Because no public evidence spoke to it. That is a real result, not a failure. It tells you the question can only be answered by asking the vendor, which is what a full assessment is for.
</Accordion>
<Accordion title="Does a re-run use fresh intelligence, or what was gathered last time?">
Fresh. Launching a run re-gathers the vendor's registration, security and people research before scoring, so a composite is never a mix of today's controls and research from months ago. The controls are re-evaluated every time regardless.
</Accordion>
<Accordion title="Why does a control show a code like ZT-SEC-04?">
That is the control's identifier, and it is stable, so you can quote it in a ticket or match it against an export. Codes are numbered within their section, so the letters tell you the area.
</Accordion>
<Accordion title="Can I re-run a vendor?">
Yes. Re-run a vendor whenever something changes or new evidence lands. Every run is its own row in the runs table, so search or filter by vendor to compare them, and the vendor's **Zero Touch Assessments** tab lists them all by date.
</Accordion>
<Accordion title="The profile describes the wrong company. Can I fix it?">
Yes. Open **Actions** > **Revise assessment** and say what is wrong in your own words, for example the right company name and website. It proposes changes to the profile fields for you to accept or reject, and applying them saves a new version of the result. To correct the vendor record itself, use **Actions** > **Reassess** with the same correction. Reassessing re-scores the run but keeps the existing profile.
</Accordion>
<Accordion title="Does the risk tier change my vendor's risk score?">
Not unless your organization turns that on, and it is off by default. Even when on, it stands down if the composite score is already configured to write to vendor inherent risk, so two things never fight over the same field.
</Accordion>
</AccordionGroup>
## Related
<CardGroup>
<Card title="Zero Touch Assessments" icon="bolt" href="/products/zero-touch-assessments">
What the capability is and where it stops.
</Card>
<Card title="How to run an assessment" icon="list-check" href="/user-guides/running-an-assessment">
The full assessment a run escalates into.
</Card>
<Card title="Financial health guide" icon="chart-line" href="/user-guides/financial-health-score">
The financial component of the composite score.
</Card>
<Card title="People intelligence guide" icon="users" href="/user-guides/people-intelligence">
The leadership dossier and adverse-media screening behind the people component.
</Card>
</CardGroup>