Record what was tested, over which period and on what sample, see what a failing verdict will cause, attach evidence, correct a result, and approve or reject a colleague's test.
A test records what someone concluded about a control over a period: whether it was designed to work, whether it actually ran as designed, and what sample that rests on. Tests drive the control's effectiveness, which in turn feeds the Controls overview, framework coverage and the risk register. Tests are never edited or deleted; a mistake is corrected by recording a new result that replaces the old one.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control from the Library in Controls. Select the Tests tab.
Task | What you need |
|---|---|
See tests, evidence and effectiveness | View controls ( |
Record or correct a test, attach or withdraw evidence | Manage controls ( |
Approve or reject another person's test in Awaiting my approval | Approve control test results ( |
Require independent testing or a second approver on a control | Manage control governance ( |
Admins can do all of these. Buttons you cannot use are not shown.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control from the Library in Controls. Select the Tests tab.
Open the control and select Tests. The panel Testing and effectiveness starts with a summary:
Item | What it shows |
|---|---|
Rating | Working, Partly working, Not working or Not yet known, with a score or no score yet. |
Last tested | The most recent test, or Never. |
Next due | The earliest date work on this control is due, or Not scheduled. |
Coverage | Targets with a current test out of targets in scope, or Nothing to cover for a control with no estate. |
A control that has never been tested reads Not yet known. That means nobody can say yet, not that the control failed. When a test is well overdue, the rating is aged down and the panel explains what it was when last tested.
The table lists every result with its Period, Design, Operation, Sample, Steps and Where. A replaced result is struck through with Corrected: and the reason. Actions offers Evidence (with the number of items) and Correct.
Each test scores its design verdict multiplied by its operating verdict. Well designed counts 1 and Design has gaps 0.25. Ran as designed counts 1, Ran, with gaps 0.5 and Did not run as designed 0. The latest counting result for each target is averaged, then multiplied by the control's coverage: a control tested on one of its three targets cannot read fully working.
Score | Rating |
|---|---|
85% or more | Working |
40% to 84% | Partly working |
Below 40% | Not working |
No test yet, or Not looked at for either verdict on any latest result | Not yet known |
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control from the Library in Controls. Select the Tests tab.
On the Tests tab, choose Record a test.
Complete the fields below. Watch for the consequence warning described in the next section.
Choose Save. The result appears at the top of the table, and the rating, coverage and Last tested update.
Field | What to enter | Rules |
|---|---|---|
What was tested | The control as a whole, or one implementation and its target. Pick the implementation to record a result for one estate item. | Defaults to the control as a whole. |
Procedure | Tick each step you completed. The dialog counts, for example, 2 of 3 steps completed. | Shown when the implementation has steps. Unticked steps are recorded with the result. |
Period from | The first day your conclusion covers. | Optional. Must not be after Period to. |
Period to | The last day your conclusion covers, not today's date. A January test of December's operation ends in December. | Required. |
Was it designed to work? | Well designed, Design has gaps or Not looked at. | Defaults to Not looked at. |
Did it actually run as designed? | Ran as designed, Ran, with gaps, Did not run as designed or Not looked at. | Defaults to Not looked at. |
Does this answer an open deficiency? | No, this is a routine test, or the open deficiency this retest answers. | Shown only when the control has open deficiencies. |
Items examined | How many items you looked at. | Whole number, at least 1. |
Of those, satisfactory | How many passed. | Needs Items examined, and cannot be more than it. |
What you concluded | What an auditor reads. Say what you examined and what you found. | Optional, but write it. |
Work completed through a form, recurring task or process run creates a test that waits for a tester's verdict, with the work already attached as evidence. Record its verdict on the Tests tab.
If you choose an open deficiency and the test passes, the deficiency closes when the result counts: as soon as you save it, or, if the control needs a second approver, when the result is approved. If it fails, the deficiency stays open and this test raises its own, so the register shows both attempts. See manage deficiencies and risk acceptance.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control from the Library in Controls. Select the Tests tab.
A test fails when Was it designed to work? is Design has gaps, or Did it actually run as designed? is Ran, with gaps or Did not run as designed. As soon as you choose a failing verdict, the dialog shows Recording this verdict will: followed by the policy that applies to the implementation you chose, and what it does:
Policy | What recording the failure causes |
|---|---|
Log only | Nothing beyond the test result itself. |
Open an exception | A deficiency in the Deficiency register, with an owner and a due date. |
Exception, then CAPA | A deficiency, and a corrective CAPA opened against it. |
CAPA directly | A corrective CAPA only, with no register entry. |
Create an action item | A deficiency, and an action item on the owner's list. |
The policy set on the implementation applies first, then the control's, then your organisation's default, which is Open an exception. Each control's Exceptions tab shows the policy in force and where it comes from. The failure policy applies when the result counts: as soon as it is saved, or, if the control needs a second approver, when the result is approved. A rejected result raises nothing.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control from the Library in Controls. Select the Tests tab.
If a control has Whoever operates this control cannot test it switched on, a test recorded by the implementation's owner, the control's owner or the person covering as delegate at the time is refused. The message names the control and asks you to have somebody else record the result, or to record a segregation exception first. The same rule applies to the Pass or Fail given when completing a Someone confirms it was done task. A test recorded under a segregation exception keeps a reference to it. See govern control definitions and versions.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control from the Library in Controls. Select the Tests tab.
Choose Evidence on a result to open Evidence — period ending followed by the date. Work completed through the control's implementation is already linked there as Completed task, Completed form or Process run; see work through due controls and record evidence.
To add more:
Choose the Kind: Link or Knowledge base.
Enter the Link or reference, such as a link to the exported user list. Required; up to 500 characters.
Under What is it?, describe it, for example "Q2 AWS IAM user export, 1 July".
Choose Attach.
To withdraw an item, choose Withdraw and give the reason when asked. The item stays in the list marked Withdrawn, with its reason, because what a conclusion rested on at the time must stay readable. Items can also show Replaced, Archived or Out of date when their validity date has passed. The dialog shows Nothing has been attached to this result yet. when it is empty.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control from the Library in Controls. Select the Tests tab.
Choose Correct on the result. The dialog is titled Correct an earlier result.
Enter the corrected verdicts and details.
Enter Why is the earlier result being replaced?. It is required.
Choose Save.
The new result replaces the old one for effectiveness. The old one stays visible, struck through, with Corrected: and your reason. A result that has already been corrected cannot be corrected again; correct the newer one.
Product location: /qms/controls/signoffs. Open Awaiting my approval in Controls.
If a control has A second person must approve each test result switched on, a recorded test does not count toward effectiveness until someone approves it. Until then the control reads as though the test had not happened. People who approve control test results receive Control Test Awaiting Your Approval.
Open Controls, then Awaiting my approval. The table lists Control, Period, Verdict, Tested by and how long each has been Waiting; anything waiting seven days or more is highlighted.
Choose Review. The dialog shows the period, the tester and both verdicts, and explains the consequence of your decision. Choose Open the control to read its tests and evidence first.
Enter a Comment. It is required when rejecting, so the tester knows what to correct, and optional when approving.
Choose Approve or Reject.
Decision | Effect |
|---|---|
Approve | The result starts counting toward the control's effectiveness from now. If it is a failing result, its failure policy is applied now. |
Reject | The result never counts and its failure policy is not applied. It stays in the record with your comment, and the tester receives Control Test Rejected at Sign-off. They record a corrected test, which needs approval in turn. |
You never see your own tests in the queue, and you cannot approve them. A result that has been corrected cannot be signed off; sign off the correction instead. Each person records one decision per test. Nothing is waiting for your approval. means the queue is empty.
Product location: /qms/controls/{controlId} (fallback: /qms/controls). Open the control from the Library in Controls. Select the Tests tab.
AC-07 Quarterly access review requires a second approver, and its production AWS implementation's failure policy is Open an exception.
In July, the internal auditor opens AC-07, chooses Record a test and picks "Review user access on the production AWS account". Period from 1 April, Period to 30 June.
They tick all three steps, sample 25 accounts, and find 22 satisfactory: three leavers still had access. Well designed; Ran, with gaps.
The dialog shows Recording this verdict will: Open an exception. They write the conclusion and choose Save.
The quality manager receives Control Test Awaiting Your Approval, reviews the result in Awaiting my approval and chooses Approve with the comment "Sample and finding confirmed".
The result now counts and AC-07's effectiveness falls. A Medium deficiency opens in the Deficiency register, owned by the cloud platform lead. It is worked and closed by a passing retest; see manage deficiencies and risk acceptance.
