Control Test Execution Procedure

Purpose

This procedure sets out how [[Organisation Name]] tests one control: how the test is planned, how the control's design is checked, how the tester takes the full list of occurrences and chooses a sample from it, how each sampled occurrence is checked, what happens when one fails, how the test is concluded and reviewed, and what follows when the control does not work. It ends with the test filed and the next one due.

It applies the Control Testing Methodology. That document says what a control test is, how large a sample must be, how often each control is tested and what counts as a pass. This one says how to run a test so that its result can be trusted: the tester is independent, the tester chooses the sample, every result rests on a record, a second person signs the workpaper, and a deficiency closes only when a retest passes.

It is written for someone who has never tested a control. Two worked examples at the end follow a test that passed with an exception and one that failed.

Legal note

This document helps you test whether your security controls work. It is not legal advice, and a test result is not a statement that you comply with NIS2, DORA, the GDPR or any standard. Where a law, a certification or a contract asks for an audit or an independent review, confirm with counsel, your certification body or the other party what it must include.

A control test under this procedure is not an internal audit, a certification audit, a maturity assessment or a statement of compliance. Its results can feed each of them. The section "What this procedure is not" says how.

Scope

This procedure applies to:

• every test of a control in the Control Inventory & Ownership Register: design checks, operating tests and retests;
• manual controls, which people carry out, and automated controls, which a system carries out once it is set up;
• every tester, whether a member of staff, internal audit or a contracted tester, when they test a control in the inventory.

It does not cover which controls are tested in which month (the Annual Control Testing Plan), what acceptable evidence looks like for each kind of control in detail (the Control Evidence Standards Checklist), how deficiencies are followed month by month (the Control Deficiency & Remediation Tracker), or how results are reported (the Control Assurance Dashboard). It does not cover security testing that attacks systems, such as penetration testing; a control test reads the records a control leaves.

Roles

The control's performer shows the tester the records and takes no other part in the test. The Head of Information Security owns most of the security controls, and so tests none of them.

Who does what at each stage

A test runs in eleven stages. Stages 1 to 8 run for every test. Stages 9 and 10 run only when a test finds a deficiency. Stage 11 closes every test. Each stage's output and rules are set out under the stage.

D: does the work. S: signs or decides. A: agrees. G: gives access to records. T: is told. "Lead" is the control assurance lead; "Owner" the control owner; "Security" the Head of Information Security.

When this procedure runs

Procedure stages

"Working days" are Monday to Friday, excluding [[public holidays]]. "Days" are calendar days. Values in [[double brackets]] are this template's defaults.

Stage 1: Plan the test

Steps:

1. Open a new workpaper on the Control Test Workpaper Template and give it the next reference, such as [[WP-YYYY-nn]]. Copy in the control's statement, owner, performer, record and attributes from the Control Inventory & Ownership Register. Copy them; do not rewrite them from memory.
2. Confirm the control's risk rating: Higher, Standard or Lower (CA-15). A key control is never Lower. A control that failed its last test is Higher until a retest passes. The rating decides which column of the sample table you use at stage 4.
3. Set the testing period (CA-06). It starts the day after the end of the last tested period, or the day the control started if it has never been tested. It ends on the last day of the period you are testing, usually the month end before fieldwork. It is never longer than the control's test cycle.
4. Check that the attributes include what every requirement the organisation relies on the control for needs (CA-17). Read the column "Requirements you rely on it for" in the Unified Control Framework Mapping Workbook. Where a requirement needs something no attribute checks, add the attribute and note why.
5. Check independence (CA-10). The tester owns and performs none of the controls they test, and the reviewer is someone other than the tester. Record on the workpaper that both have checked this.
6. Agree dates with the control owner: when the population will be extracted, when the walkthrough happens, and the fieldwork days. Ask for read-only access to the system of record, or a supervised extraction, so the test reads records and changes nothing.
7. If an audit, a supervisory review or a customer review will rely on the test, note its date. The test must be final, with the reviewer's signature, at least [[6]] weeks before it starts (CA-16).

The rules this stage applies:

CA-06 The testing period runs from the end of the last tested period, or from when the control started, to the end of the period being tested, and is never longer than the control's test cycle. A control that has not yet run in the period is Not tested, with the reason.

CA-10 No one tests a control they own or perform (P08 IS-07, P19 MA-14). A check by the owner is recorded as a self-check: it does not count as a test, and the control stays untested.

CA-15 Each control is rated Higher, Standard or Lower risk, and tested at least every 6, 12 or 24 months respectively. A control never tested is due within one cycle of the start of the first plan year, or of the day it started if that is later; one whose design was found deficient, within one cycle of the day its design is found adequate. A key control is never Lower, and a control that failed its last test is Higher until a retest passes.

CA-16 The sponsor approves the year's test plan before it starts, and any change to it is recorded. Tests that an audit, a supervisory review or a customer review will rely on are final at least [[6]] weeks before it starts.

CA-17 Test once, rely on it many times: one test supports every requirement the organisation relies on the control for, as long as the attributes tested include what each of those requirements needs. Which requirement a control is relied on for is the organisation's own record in the workbook; P20 does not say it.

The independence rule is P08's IS-07, "Internal auditors must not audit their own work", applied to a control test, as P19's MA-14 applies it to a maturity assessment. A control is your own if you own it, carry it out, manage the people who carry it out day to day, or wrote the procedure it follows.

Stage 2: Walk the design through

Steps:

1. Read the written statement. Check that it says who does what, how often, and the record it leaves (CA-01). If there is no written statement, the control has a design deficiency: record Deficient, stop, and go to stage 9.
2. Ask whether the control, if it ran exactly as written, would keep its risk in check. Does it reach every system and person in scope? Is its timing tight enough? Does the person who checks look at the thing that matters? A control that could not work even when followed is Deficient.
3. Choose one recent occurrence yourself. Follow it with the performer from the trigger to the record: the event that started it, each action, each approval, and the record left at the end. Inspect each record as you go (CA-03).
4. Note what has changed since the last design check: the system, the people, the procedure or the volume. A design check is needed at least every [[12]] months and whenever the control changes (CA-02).
5. Record Adequate or Deficient, with the reasons and the references of the records you saw. If Deficient, the operation is not tested: record Not tested for the operating conclusion, give the reason, and go to stage 9.

The rules this stage applies:

CA-01 A control is tested against its written statement: who does what, how often, and the record it leaves. A control with no written statement, or one whose statement could not keep its risk in check, has a design deficiency, and its operation is not tested until the design is fixed.

CA-02 Design is checked before operation: a walkthrough of one occurrence from start to record, at least every [[12]] months and whenever the control changes. An operating test is made only on a design found adequate.

Stage 3: Take the population and check it is complete

Steps:

1. Find the system of record: where the event that triggers the control is recorded, apart from the control itself. For leavers it is the HR system's leaving dates, not the list of accounts removed. For vulnerabilities it is the scanner's detections, not the list of fixes. The second source must be one the control does not feed; a list the owner keeps by hand never is.
2. Extract the list yourself, or watch it being extracted (EQ-05). Record the system, the report or query, the date and time it was run, the filter and the count.
3. Keep only the occurrences whose trigger falls inside the testing period.
4. Check the list is complete against a second source (EQ-04). The counts should agree. Where they do not, find out why for each difference, and add any missing occurrence to the population.
5. If you cannot show the list is complete, do not sample from it. A list the tester cannot check is not a population (CA-04). Record why, and escalate to the lead.
6. If the population is empty, the control has not run in the period. Go to the section "When the control has not run".

The rule this stage applies:

CA-04 The tester takes the population from the system of record, checks it is complete against a second source, and chooses the sample, spread across the testing period. The control owner never chooses the sample or supplies a list the tester cannot check.

The evidence standard EQ-04 applies to the population as much as to any record: "A report or list used as evidence shows its source, when it was run and the filter used, and the tester checks its count against a second source (CA-04)."

Stage 4: Choose the sample

Steps:

1. Count the population and find its band in the sample table below. Read the size from the Higher column for a Higher control, and the Standard column for a Standard or Lower one.
2. Where the population is no larger than the sample, test every occurrence.
3. Spread the sample across the testing period. Sort the population by date, divide it into as many equal parts as the sample size, and choose one occurrence from each part with a random number. Record how you chose: the tool and the numbers it gave.
4. Never let the control owner or the performer choose, suggest or remove an occurrence. Do not tell them which occurrences you chose until you ask for the records.

The rule this stage applies:

CA-05 The sample size comes from the population band and the control's risk rating. When the population is no larger than the sample, every occurrence is tested.

The sample, by the number of times the control ran in the testing period:

These sizes are the pack's defaults, in line with common practice for testing recurring controls. They are not statistical samples. You may raise them; never lower them for one test. A monthly control tested over 12 months has a population of 12, and a sample of 2, or 3 if it is Higher risk.

Stage 5: Test each attribute

Steps:

1. For each sampled occurrence, gather the evidence for each attribute by inspection, observation or re-performance. Ask questions to understand what you see; an answer is never the evidence (CA-03).
2. Check each piece of evidence against the six standards below (EQ-01 to EQ-06) and the kind of evidence the Control Evidence Standards Checklist sets for the control.
3. Record Pass or Fail for each attribute, with the evidence's reference and date. An occurrence that fails any attribute is an exception.
4. Where a record cannot be found, the attribute fails. Where the control ran but its record falls short of the evidence standard, the attribute fails too; note that the shortfall is in the record, because it decides the severity at stage 9.
5. Do not let anyone create or correct a record during the test. A record made after the occurrence does not show that the control ran on time (EQ-02).

The rule this stage applies:

CA-03 Asking someone is never enough. Every test inspects records, observes the control being done, or re-performs it; an interview only explains what the tester saw.

The ways a tester gathers evidence:

Every piece of evidence must meet these standards:

The Control Evidence Standards Checklist sets what acceptable evidence looks like for each of 8 kinds of control, from "approval before action" to "system setting", with examples of evidence that does not count.

Stage 6: Handle exceptions and extend the sample

Steps:

1. For each exception, write down what failed, by how much (days late, the account left open, the approval missing), and the reason the owner gives. The reason explains the exception; it does not remove it.
2. If another control caught the failure later, write that down too. It is still this control's exception (CA-08). The other control counts when the deficiency is rated, at stage 9.
3. Count the exceptions. None: go to stage 7. One, in a manual control whose population is at least twice the sample: extend the sample. Any other case: the result is Not effective; go to stage 7.
4. To extend, choose the same number of occurrences again from the ones not yet sampled, spread across the period and chosen the same way. Test every attribute of each.
5. Never replace or drop the occurrence that failed. It stays in the sample, and on the workpaper, whatever the result.

The rules this stage applies:

CA-07 No exception: Effective. One exception in a manual control whose population is at least twice the sample: the tester adds the same number again, new occurrences chosen the same way, and concludes Effective only if none of them fails, recording the exception. Otherwise, and for any exception in an automated control (even one sampled as a manual control under CA-09) or in a whole population, Not effective.

CA-08 A sampled occurrence that fails an attribute is an exception, even if another control later caught and corrected it. The other control counts when the deficiency is rated (CA-12), not when this control is concluded. This differs from P19's MA-05 on purpose: P19 rates a whole practice with its checks, P20 one control.

CA-08 differs from P19 on purpose. P19's maturity assessment rates a whole practice, and a failure the practice caught and corrected with its own checks shows that the practice works (P19 MA-05). A control test rates one control. If another control caught the failure, that is evidence the other control works, and it counts when this control's deficiency is rated. It does not turn this control's failure into a pass.

Stage 7: Conclude

Steps:

1. Apply the conclusion table below. There are three words a test can end in: Effective, Not effective and Not tested.
2. Write the result as counts: the population, the sample, how many passed, and the extension and how many of it passed. Never write it as a share.
3. Where the result is Effective with one exception, name the exception in the conclusion. It is recorded, not forgotten.
4. Write one sentence the dashboard can quote: control, testing period, population, sample, exceptions, conclusion. Work out when the next test is due from the end of the testing period and the rating (CA-15), for the Control Inventory & Ownership Register.

The rule this stage applies:

CA-19 Results are reported as counts, such as "21 of 30 controls tested", with every deficiency named. There is no overall assurance score, no weighting, and no figure presented as a share of compliance with any framework.

The conclusion, for each situation. The figures are population, sample and exceptions:

Stage 8: Review and sign the workpaper

Steps:

1. Review the workpaper within [[10]] working days of the last test step (CA-11).
2. Check, in this order: the population's source and completeness; that the tester chose the sample and spread it; that every result rests on evidence that meets the standards; that every exception is described and none was dropped; that the conclusion follows the table; and that tester and reviewer are independent.
3. Send any question to the tester in writing. The tester answers on the workpaper, adding evidence where needed.
4. Sign and date the workpaper. The conclusion is final only when you sign. If you disagree with the conclusion and the tester does not change it, the lead decides and records both views.
5. The date you sign is the day any deficiency the test raised is confirmed. Its plan and due dates count from it (CA-13).

The rule this stage applies:

CA-11 Every test is recorded on a workpaper with the population and its source, the sample, the attributes, the result for each, the exceptions and the conclusion. Someone other than the tester reviews it within [[10]] working days of the last test step; the conclusion is final only when they sign.

Stage 9: Log the deficiency, rate it and agree the plan

Steps:

1. Log the deficiency in the Control Deficiency & Remediation Tracker on the day the reviewer signs: its reference ([[DF-nn]]), the control, the workpaper, whether it is a design or an operating deficiency, and what was found.
2. Rate it High, Medium or Low with the severity table below (CA-12). Use a compensating control only if it has itself been tested and found effective.
3. Set the dates: the plan is agreed within [[10]] working days, and the fix is due [[90]], [[180]] or [[365]] days after the reviewer signed, by severity (CA-13).
4. Tell the risk owner at once: every risk on the register that relies on the control. They decide whether the risk must be reassessed. A High deficiency also goes to the assurance sponsor and the approver in the next report.
5. Agree the remediation plan with the control owner: what will change, who will do it, by when, and what record will show the fix. The Head of Information Security agrees it for a security control. Where other work already planned will fix the control, link that work in the tracker; do not start a second action.
6. Rate the control Higher in the Control Inventory & Ownership Register until a retest passes (CA-15), and add the retest to the Annual Control Testing Plan.
7. If the fix cannot be made by the due date, the owner requests a P02 exception before the due date passes. A deficiency is deferred in no other way (CA-13).

The rules this stage applies:

CA-12 Every design deficiency and every Not effective result is a deficiency. High: a key control failed and no compensating control was tested effective, or the failure leaves a risk outside appetite or a recorded unmet obligation without its control. Medium: a key control failed but a compensating control was tested effective, or a control that is not key failed. Low: the control ran, but its record falls short of the evidence standard.

CA-13 The owner agrees a remediation plan within [[10]] working days and fixes the deficiency within [[90]] days for High, [[180]] for Medium and [[365]] for Low, from the day the reviewer confirms it. The risk owner is told at once; a High deficiency goes to management in the next report. A deficiency that cannot be fixed in time is deferred only as a P02 exception.

The severity, and the time to fix it from the day the reviewer signs:

Stage 10: Retest and close

Steps:

1. The owner tells the lead the fix is in place, and the date it took effect, with the record that shows it.
2. Wait until the fixed control has run at least [[2]] times, or once for an annual or automated control (CA-14).
3. Retest through stages 1 to 8, with a new workpaper. The population is the occurrences since the fix took effect. A design deficiency is retested with a new walkthrough first, then an operating test once the control has run enough times.
4. If the retest passes, close the deficiency with the retest workpaper's reference and the date the reviewer signed it. The control's rating returns to what its risk and key status set.
5. If the retest fails, the deficiency stays open. Agree a new plan, tell the risk owner again, and keep the original due date unless an approved P02 exception moves it.

The rule this stage applies:

CA-14 A deficiency closes only when a retest passes. The retest waits until the fixed control has run at least [[2]] times, or once for an annual or automated control, and is made by someone other than its owner.

Stage 11: File and keep

Steps:

1. File the signed workpaper with all its evidence in [[the assurance file]], where the tester and reviewer can reach it and the control owner cannot change it (CA-20).
2. Keep it for [[3]] years, or longer where a law or a contract asks.
3. Workpapers hold personal data and security detail. Keep in the file only what the test needs, references in place of copies where they are enough, with access limited to the people who test and review.
4. Update the Control Inventory & Ownership Register with the conclusion, the date and the next test due; mark the test delivered in the Annual Control Testing Plan; and pass the counts to the Control Assurance Dashboard.

The rule this stage applies:

CA-20 Workpapers and the evidence they rely on are kept for [[3]] years, or longer where law or a contract asks, where the tester and reviewer can reach them and the control owner cannot change them.

When the control has not run

A control that did not run in the testing period has nothing to sample. Its operating conclusion is Not tested, with the reason (CA-06). The reason matters: "no leavers in the period" is not the same as "the review that should have happened did not". If the control should have run and did not, that is a failure of the control: test it as one occurrence that failed, and conclude Not effective.

Not tested is also the operating conclusion when the design is Deficient (CA-01). The design deficiency goes to stage 9, and the operating test waits for the fix.

EXAMPLE. The pilot had both cases. WP-2026-06 tested CT-20 "Privileged access reviewed": Design walked through on the Privileged Access Standard approved on 18 Sep 2026. Not tested: no review has yet fallen due; the first is due by 21 Dec 2026. WP-2026-07 tested CT-02 "Policy reviews on time": Design deficient: with no register of review dates, nothing shows when a review falls due, and there is no cryptography policy to review (CA-01). Operation not tested until the design is fixed. That design deficiency is DF-02, also rated High.

Automated controls

CA-09 An automated control is tested once for each configuration, and that test holds only while change control over the system was itself tested effective for the same period. Otherwise it is tested as a manual control.

For each automated control:

1. Name each configuration that makes the control work: the setting, the rule or the job, on each system where it runs. Each configuration is tested once.
2. Obtain the setting as it stands, exported or observed by you, with the system's name and the date (evidence type ET-08).
3. Re-perform the control once for each configuration: give it an input it should act on and one it should let through, and record what it did. In a live system, use a test account or a test record agreed with the owner.
4. Obtain the change record for the setting over the testing period. Any change must have gone through the system's change control.
5. Check that change control over that system was itself tested and found effective for the same period. If it was not, test the automated control as a manual one: population, sample and attributes, as in stages 3 to 6.
6. One exception in an automated control is Not effective. There is no extension (CA-07).

A check made by the control owner

An owner who checks their own control is doing their job, and it is worth doing. It is not a test, because no one tests a control they own or perform (CA-10). When an owner's check reaches the control assurance lead:

• Record it as a self-check on the workpaper, with who made it. It is not a test.
• The control stays untested in the Control Inventory & Ownership Register and on the dashboard.
• Use what the self-check found. If the owner found an exception, treat it as a warning: bring the test forward.
• Never let a self-check replace a planned test because there was no one else to do it. Escalate that instead.

Deficiencies past their due date

A deficiency is fixed by its due date, or deferred as a P02 exception requested before the due date passes. It is never deferred by changing the due date in the tracker (CA-13). The exception is scored with P02's model and approved by the approver its band sets, for no longer than the band allows: 365 days for a Low exception, 180 days for a Medium exception, 90 days for a High exception and 30 days for a Critical exception.

When to escalate, at any stage:

What this procedure is not

CA-18 Control testing is not an internal audit, a certification audit, a P19 maturity assessment or a statement of compliance, and is never presented as one. Its results can feed each of them.

A control test under this procedure is not the ISO/IEC 27001 internal audit (the ISO 27001 Implementation & Certification Readiness pack, P08, covers that). It is not the internal audit of the ICT risk management framework that DORA Article 6(6) and Delegated Regulation (EU) 2024/1774 Article 28(5) require of financial entities. It is not the independent review in point 2.3 of the Annex to the NIS2 Implementing Regulation (EU) 2024/2690, which binds only the providers its Article 1 names. It is not a maturity assessment under P19.

Each of those has its own rules on who may carry it out and what it must cover. A control test can feed each one: an auditor may rely on a signed workpaper, re-perform part of it, or use its deficiencies to choose what to audit. Whether they do is their decision, not the tester's.

Worked example: a test that passed with an exception

EXAMPLE, not part of the procedure. The organisation used throughout the pack is a wholesale distributor with about 900 staff, an important entity under NIS2 in its Member State. Its control assurance lead is its Quality and Compliance Manager, who owns and performs no control in the inventory. The pilot round TR-2026-P ran from 21 Sep 2026 to 25 Sep 2026 and tested 1 Mar 2026 to 31 Aug 2026. The Internal Audit Manager reviewed the lead's workpapers. Replace every value with your own.

EXAMPLE. The 10 leavers tested:

Worked example: a test that failed

EXAMPLE. The second pilot test, WP-2026-02, ran the same stages on CT-13 "Urgent vulnerabilities fixed in time" (P01 VM-08). Owner: Head of IT. A key control, rated Standard when tested.

EXAMPLE. The 5 findings tested:

Checklist for one test

Workpaper [[WP-YYYY-nn]] · Control [[CT-nn]] · Tester [[role]] · Reviewer [[role]]. Tick each line before the reviewer signs. Stages 9 and 10 apply only when the test raised a deficiency.

Related documents

Adapting this template

Framework references

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774; Regulation (EU) 2016/679 (GDPR).

ISO/IEC 27001 references name the clause or control this document relates to. They do not say that meeting it meets any other framework's requirement.

Definitions