Control Testing

    Executing, reviewing, and evidencing control tests

    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 - the outcome: pass, fail, or not applicable.
    • 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:

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

    The approved or rejected result becomes the authoritative outcome. If the control does not require review, the test result is immediately authoritative - no review step is needed.

    Automatic Issue Creation

    When a test result is a failure, Anzen automatically creates an issue with the following defaults:

    • Title: "Control failure: [control title]"
    • 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. This issue then feeds into the risk report, connecting failed controls to risk exposure.