--- title: "Controls, testing & evidence" summary: "Control objectives and the catalogue, how tests and evidence work, external test review, and design versus operating effectiveness." updated: "2026-10-07" section: "Compliance library" url: "https://zovos.ai/docs-controls.html" --- # Controls, testing & evidence Controls in Zovos come in two layers. A **control objective** states what has to be true. A control in the **Control catalogue** is one business unit's instance of that objective, with its own owner, test history and effectiveness rating. Together they record what each control covers, who runs it, how it is tested, and which regulations it answers to. Controls are one of the two things coverage is measured against, the other being your policies. ## Control objectives and the catalogue ### Control objectives **Control objectives**, in the Library group, is the register of templates. Each objective has an identifier, a family, a status of draft, active or retired, and the citations it maps to. The citation mappings live on the objective rather than on each instance, so coverage counts an obligation once instead of once per business unit. An objective can also carry a template test procedure, which each instance may override for its own unit. Choose **Instantiate** on an objective to create a control for one or more business units. Each unit gets its own control with its own owner, test history and effectiveness rating, and the objective stays the single statement of what has to be true. Retiring an objective requires a reason, and its consequence is shown before you confirm. Every approved link on the objective and on its instances, citation mappings included, drops back to needs review, so coverage that relied on those links stops counting until someone approves them again. Nothing is deleted. The objective, its instances and their test history stay on the record, and the objective can be made active again. ### Building the catalogue The fastest start is **Import baseline**, which offers five baselines: - **NIST 800-53 Rev. 5 Moderate Starter Set.** A representative starter set of NIST SP 800-53 Rev. 5 controls for a moderate baseline. - **CIS Controls v8 Implementation Group 1 Starter.** A representative starter set from CIS Controls v8 Implementation Group 1. - **FFIEC IT Examination Core Control Set.** A core control set aligned to the FFIEC IT Examination Handbook booklets. - **Cyber Hub: FFIEC IS, NIST CSF 2.0, CRI Profile, GLBA, NCUA Part 748, ISO 27001.** Sixteen cybersecurity objectives, each mapped across the frameworks in its name. - **AI and Model Risk Hub: SR 26-2, ISO 42001, NIST AI RMF, FS AI RMF, Colorado and state AI laws.** Ten objectives for governing models and AI, each mapped across the frameworks in its name. Importing a baseline creates one control objective for each baseline control, already mapped to the citations it answers to, and one enterprise-wide instance of each, so the catalogue is usable immediately. Importing the same baseline again duplicates nothing. The two hubs are crosswalks. One tested objective shows where it lands in every framework an examiner works across. Each hub mapping states how completely the objective covers the citation, as equal, subset, superset or intersects, and the citation drawer shows that relation under **Same ground in other frameworks**. See [Frameworks & regulatory updates](docs-frameworks.html). You can also import your own controls or add them one at a time. The importer takes a CSV or an XLSX spreadsheet and validates it in a dry-run pass first. It reports errors row by row without abandoning the rest of the file. Each row is matched on the control objective's name and lands on the instance for the business unit it names, so a re-import updates the same records instead of duplicating them. Each control needs an objective, an owner, and the citations it satisfies. That last part is what turns a list of controls into coverage, because gap analysis compares your obligations against the controls and policies you actually have. Controls carry a few attributes that examiners read closely: - **Type.** A control is preventive, detective, or corrective. - **Automation.** A control is automated, hybrid, or manual. - **Key control.** A key control is one whose failure would be material. Key coverage is tracked as its own percentage. - **Evidence freshness.** Evidence reads fresh, expiring, or stale, so a control that passed a year ago does not read as current. The catalogue's needs-attention chips surface tests due, tests overdue, and stale drafts, which is the shortest path from opening the screen to knowing what is actually late. The catalogue lists one row per instance and can be filtered by business unit. It also carries the shared register tools described in [Dashboard & daily triage](docs-dashboard-triage.html). Those are sortable columns, column visibility, saved views of the filter and layout you work in, and an audited import-ready CSV export of the whole catalogue. Any custom fields your workspace has defined for controls appear on the control itself. A control's link to its governing policy opens that policy's **Coverage** view in **Governing docs**, which lists every control that implements it. If you license a publisher's control catalogue, the **Content library** is where that imported content becomes readable. It shows each imported control, the framework crosswalk the publisher shipped with it, and how it lines up against your own catalogue. Mapping suggestions are proposals. Nothing links to your controls until you confirm it, and each decision is audited. Importing the file itself still happens in Settings, and an examiner session never reaches this screen. ## Design versus operating effectiveness Zovos tracks two effectiveness ratings and does not let them collapse into one. **Design effectiveness** asks whether the control is built to achieve its objective, that is, whether it would work if it ran as written. **Operating effectiveness** asks whether it actually works in practice, and it is test-derived. You cannot simply declare a control operating effective. The rating comes from testing and from an independent review. Both roll up on the catalogue screen as stacked bars, with values of not yet assessed, effective, partial, ineffective, or exception. The distinction matters at exam time, because a well-designed control that has never been tested is a different finding from a control that was tested and failed. ## The test workflow Testing a control runs in a short loop: 1. **Schedule the test** on the control's cadence. 2. Choose **Run test** and record the result, which is the samples tested and the samples passed. 3. **Attach evidence** of the test to the control. Evidence carries its own freshness clock. 4. **Attest** to the control, recording that a named person stands behind it. 5. Choose **Request effectiveness review** for an independent sign-off, which is what can raise operating effectiveness. The last step is the important one. A control owner attesting to their own control is a useful record, but it is not independent assurance. The effectiveness review routes to someone else through the approvals queue, and only that independent sign-off moves the operating rating. ## Automated and external tests ### Continuous control monitoring Where a control can be evidenced by a system rather than a person, add an automated test. Choose a **Connector**, a **Check**, and a **Cadence**, then let it run. The **Check** list offers only the checks the chosen connection can actually run, and a check paired with a connection that cannot run it is refused. You can also choose **Run now** for an ad hoc check. Typical checks cover multi-factor authentication enforcement, second-step verification enrollment, vulnerability posture, endpoint coverage, mobile device management, cloud configuration in AWS, and automated backups that are configured and current. A failed automated run opens a remediation finding for you. There is one open finding per control, so a test that keeps failing does not pile up duplicates. That is one of the few places in the product where a finding is created without a human click. Automated checks need a connected system. The panel points you to Settings and integrations if nothing is connected yet. See [Connecting integrations](docs-integrations.html). ### External test review Some tests are performed outside Zovos by your own AI assistant and submitted over the Zovos Evidence Protocol. **External test review**, in the Library group, is the reviewer inbox for them. Its **Pending review** tab lists submissions waiting for acceptance. Its **Re-perform** tab lists submissions that random re-test sampling flagged for an independent re-performance. Each row shows the control, the test period, the outcome, the tester of record, the target system and the attached artifacts. The tester of record is the verified person who submitted the test. The assistant's name is self-declared, so it is badged as unverified. Open a row to review the full submission on the control. A reviewer who is not the tester and who holds the control-approval permission accepts or rejects it, and a rationale is required either way. For a sampled item, the reviewer records the re-performance as a match or a mismatch, with a note. An examiner never accepts, rejects or re-performs a submission. See [Test controls with your own AI assistant](docs-ai-control-testing.html). ## Management certifications The catalogue's second tab holds certification campaigns. These are the sub-certification rounds that support FDICIA and SOX internal control over financial reporting sign-offs. Open a new campaign, and each responsible manager either certifies or **certifies with exception**, optionally opening a finding at the same time. When the round is complete you submit it for close and export a committee pack as a PDF. Certification is not the same as attestation. Attestation is a named person signing that a policy or control is in place. Certification is a periodic, structured round tied to financial reporting. ## Over-relied controls The [coverage graph](docs-frameworks.html) badges some controls as **over-relied**. That means so many citations depend on that single control that it has become a concentration. If it fails, a large part of your compliance story fails with it. It is not automatically a problem, and the product does not treat it as a finding. It is a prompt to either document why the reliance is appropriate or build a second control so one failure does not cascade. Examiners ask this question in a different vocabulary, usually about single points of failure in the control environment. ## Notes and limits Zovos does not connect to core banking, loan origination or AP systems. Your testers draw populations and samples from those systems themselves, and each test records how many items were sampled and how many passed. That is a deliberate scope decision. Zovos holds the risk and control work of every line of defense, and it stays out of transactional banking. Beyond the five baselines in **Import baseline**, the control catalogue ships no third-party control content. You bring your own baseline, or import content you are licensed to use.