Connecting integrations

Most of the evidence a compliance program needs already exists somewhere else. It sits in your document management system, your identity provider, your ticket tracker and your vendors' rating services. Connectors bring that evidence in with its source and its timestamp intact, so you are not screenshotting it by hand the week before an examination. Connectors ship disabled. Nothing is fetched from or sent to an outside system until an administrator connects it with a credential your institution controls.

How connecting works

Connections live on the Integrations tab of Settings & integrations. Tiles are grouped by the job they do. Each tile shows its direction (inbound, outbound, or two-way), how it authenticates, and its current status. The status is one of Available, Connected, Pending, Attention needed, or Disconnected.

Connecting means providing one of a small number of things:

• OAuth or admin consent. You sign in to the provider and approve a named application against a listed set of permissions. This is how Microsoft 365, Google, Box, Confluence, iManage, NetDocuments and the GitHub repository readings connect. DocuSign uses a one-time admin consent for a service user instead of a per-signer sign-in.
• An API key or token. You issue it in the vendor's own console and paste it once. Jira, ServiceNow, Azure DevOps, GitHub Issues, GitLab Issues, security-evidence and vendor-rating services work this way.
• A cross-account role. Amazon Web Services connects through a read-only role you create in your own account. Zovos can assume it only with an external ID that you and Zovos share.
• A webhook secret. Systems that push events to you use one. It is verified on every delivery and replay-deduplicated.
• A pinned SSH host key. SFTP delivery requires one. It is not optional.

Two credentials run the other way. An API key and a KRI ingest token are both issued by Zovos so your own systems can call us. Those are covered below.

Credentials are encrypted at rest and never sent back to a browser. You can replace a secret, but you cannot read it. Every URL you supply must be https and is checked before it is stored or fetched. Creating or changing a connection is a settings-level permission and is written to the audit trail like any other governed change.

Two habits save trouble later. First, use a dedicated service account with read-only scopes instead of a person's account, so the connection does not break when that person leaves. Second, decide who owns the credential before you connect. Connectors that pull evidence for a control test become part of your examination story.

What the catalog covers

How we describe connector readiness

The integrations page publishes where each connector stands, in one of two states:

• Available. The connector runs against the real service today, on a credential you already have.
• Coming soon. The adapter is still in progress. Adobe Acrobat Sign is in that state today. Its tile is visible and badged, and it is refused as a connection and as a send target instead of accepting envelopes that would fail on the first send. DocuSign is the e-signature provider you can use today.

Inside the product, a tile shows something different. It shows your own connection status, which is one of Available, Connected, Pending, Attention needed, or Disconnected. A tile that is not connected says so plainly instead of showing a stale reading.

Your own API access

Not every integration is a tile. Where you want to pull your own data into a warehouse, a business-intelligence refresh, or an automation scenario in Zapier, Make or n8n, your workspace owner can mint a tenant API key from the integrations settings.

• Scopes are chosen when the key is minted and do not change afterwards. Read scopes cover findings, the risk register and its assessments, the control catalogue, the policy register as metadata rather than document text, and the third-party register. A write scope lets a key open findings and add comments. The scope to read integration settings is required to connect an automation platform. Another scope lets it manage its own event subscriptions, which is what makes a trigger fire.
• The secret is shown exactly once, and only its hash is stored. Minting, listing and revoking are audited, and a revocation takes effect on the very next request.
• A key acts as your institution, not as a person. What it writes is stamped as a system actor. That is why no governance decision is reachable through it.

The reference for what a key can call is generated from the live routes rather than hand-written, so it cannot describe a surface that no longer exists. Ask your Zovos contact for the current copy and your developer or integrator can work from it.

There is a second, narrower credential. A KRI ingest token lets an external metric feed push readings into one key risk indicator. Each token covers one indicator in one workspace, has no session, and carries an expiry you set. The panel that mints it is also the live inventory of what can write into that indicator, with a kill switch on each token.

What flows in, and what flows out

Inbound, connectors bring documents into your library, where they become searchable and citable. They bring control readings that attach to a control test with the system they came from and the time they were taken. They bring vendor ratings as a time series with a delta against the previous reading. They also bring program-level AML metrics, regulatory change and market data.

Outbound, Zovos forwards audit events, delivers scheduled datasets, opens and updates tickets, sends signature envelopes, posts notifications, and assembles board and regulator packages.

Nothing fails silently. If one delivery leg of a scheduled export fails, the whole run is marked as an error and a delivery alert is raised. The run does not report success. Ratings that drop materially append a monitoring event automatically, but they never force a reassessment. That decision stays with the third-party risk manager.

Acting from Slack

The basic Slack and Microsoft Teams connections post notifications to a channel through an incoming webhook. The interactive Slack app goes further. An administrator connects it by pasting the app's bot token and signing secret, then links each Slack user to their Zovos member.

• Approve or reject. A linked user can approve or reject an item from the message itself. Each decision asks for a required rationale and runs through the same approval rules as the web app, including separation of duties.
• Acknowledge. A linked user can acknowledge a finding or an attestation, within the same permissions they hold in Zovos.
• Look up work. The /zovos command lists your pending approvals and overdue attestations and looks up a finding by its ID. It only reads, and only you see its replies.

Every action taken in Slack is written to the audit trail with Slack recorded as the channel. A Slack user who is not linked, or who lacks the permission, is told so and nothing is written.

What an examiner sees

Every sync keeps an append-only run log of what was pulled, when, and what came back. That record answers "when did you last actually check this", which is the question that follows every assertion of continuous monitoring.

Evidence carries the source system and the collection time with it, so a control test shows where its reading came from. Vendor ratings are snapshots over time, so the number never changes quietly. Closure stays with a person. When a linked ticket is marked done in your tracker, the finding moves to awaiting review. It never signs off its own closure. Governance decisions are deliberately outside the automation surface entirely. Approving a policy or accepting a closure requires a named person under separation of duties, and no automation recipe can do it for them.

Limits worth stating plainly

• No core banking or loan-origination connector. Leaving out Fiserv, Jack Henry, FIS and Symitar is deliberate. Zovos holds the risk and control work of every line of defense. It is not a system of record for transactions. Monitoring populations and samples arrive by import.
• No accounts-payable or ERP connector. Shadow-vendor reconciliation runs from a CSV you export.
• No two-way sync with another GRC platform. Records do not flow back and forth between Zovos and another GRC tool.
• Zovos sends no emergency alerts. The business-continuity connector keeps your mass-notification tool in step with the plan register by sending it a signed event. Zovos itself sends no SMS, voice or push messages and holds no contact roster. Emergency alerting stays with the operational tool you already use.
• Some connections do not refresh their own tokens. When the vendor's token expires, runs start failing and you reconnect. Watch the Attention needed state.
• Adobe Acrobat Sign waits on an application registration before it can be self-served. Its tile shows as Coming soon until the registration completes. If it is blocking you, tell us. We set connector priority by what customers are actually stuck on.