Control Testing - Anzen Docs

How Testing Works

A control test is an execution of a control's test procedure. The tester follows the documented steps, records their findings, and submits a result. Each test receives a sequential test number (TST-0001, TST-0002, and so on).

Test States and Scheduling

A test is in one of three states:

Scheduled - automatically generated by the system based on the control's test frequency (daily, weekly, monthly, quarterly, or yearly). For each upcoming period a scheduled test is created and assigned to a tester. Controls with no frequency stay ad-hoc and produce no scheduled tests.
Overdue - a scheduled test whose due date has passed without a result being recorded. It stays assigned until the tester completes it.
Completed - a tester has recorded a result, and the test moves into the historical record.

On a control's detail page the Tests tab lists every test for that control across all states, with one row per test showing the status, result, tester, period covered, due date, and review state. Use the "only show tests assigned to me" checkbox to narrow the list to your own work.

What a Test Captures

Each test records the following information:

Result - a graded outcome: pass, partial, fail, or not applicable. A partial means the control is only working in part; a fail means it is not working. Both partial and fail weaken the mitigated risk's residual score.
Evidence - a text description of what was observed during testing.
Notes - additional notes or context from the tester.
Tester - the user who executed the test (set automatically to the current user).
Test date - the timestamp of when the test was executed.

Evidence Attachments

Testers can upload file attachments as evidence to support their test result. These attachments are stored against the test record and are accessible from the test detail view. Common evidence includes screenshots, log exports, configuration dumps, or compliance scan reports. The maximum file size is <strong>50 MB</strong>. See <a href="/docs/tickets">Tickets</a> for a full list of supported file types - the same types are accepted for control test evidence.

Review Workflow

If the parent control has review enabled, every test enters a review workflow after submission:

The tester submits the test. The review status is set to Pending.
A reviewer (who must be a different user from the tester) examines the result and evidence.
The reviewer either approves or rejects the test, optionally adding review notes.
The reviewer and the review timestamp are recorded.

Under this four-eyes review the <strong>reviewer</strong> determines the final grade (pass, partial, or fail) that becomes the authoritative outcome. If the control does not require review, the grade recorded by the control owner is immediately authoritative - no review step is needed. The authoritative grade is what drives the residual score of any risks this control mitigates.

Automatic Issue Creation

When a test is graded partial or fail, Anzen automatically creates an issue with the following defaults:

Title: "Control failure: [control title]" for a failed test, or "Control degradation: [control title]" for a partial test
Severity: medium
Status: Open
Entity: inherited from the control's owning entity
Links: the issue references both the control and the specific test that triggered it

A system comment is added to the auto-created issue noting which test triggered it. The issue is also fanned out to every risk this control mitigates, and those risks' actual (current) residual scores rise toward inherent until the control is performing again. This feeds into the risk report, connecting under-performing controls to risk exposure. Overdue or never-tested controls weaken the actual residual in the same way, even before a graded result exists.