Control Inventory & Ownership Register
Lists implemented controls with owner, frequency, evidence produced and test status.
Available soon
- Format
- Excel
- Size
- 91 KB
- Length
- 12 sheets
- Version
- 1.2
- Updated
Follow this documentFree account. We can email you when it changes.
What's inside
What changed
- 1.2
The restore-testing note names P23's Restore Testing Methodology.
- 1.1
The restore-testing note names P22's RR-14.
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | What this register is. The list of controls your organisation tests, kept by the control assurance lead. The Annual Control Testing Plan schedules from it, and every workpaper (Control Test Workpaper Template) names a control from it. |
| 2 | Read the Inventory sheet first: the 30 controls CT-01 to CT-30, each quoting a rule a published pack already sets, filled in for the EXAMPLE organisation. Yellow columns are inputs; white ones calculate. |
| 3 | Decide which of the 30 controls you run. Copy those rows to the Blank inventory sheet, columns B to M (the control itself, its source and its evidence type). Leave out a control you do not run, and add a row for every control you run that the set does not hold, using the Adding your own controls sheet. |
| 4 | Check each statement against what really happens. Where your practice differs from the source rule, write what you do and note the difference: you test the control you run (CA-01). |
| 5 | Name each control's owner: the manager accountable for it running and leaving its record. A person or a role, never a team. |
| 6 | Decide whether each control is key, and give it a risk rating, with the Risk rating guide sheet. A key control is never Lower; a control that failed its last test is Higher until a retest passes (CA-15). For a Higher control, write why. The Rating check column flags a rating the rules do not allow. |
| 7 | Record each control's last test: the workpaper reference, the end of the period it covered, the operating conclusion, the design status and the date the design was last walked through. A control never tested has no period end: its first test is due one cycle after the plan year starts, or after the day the control started if later (CA-15). Enter that day in 'Control started on'. |
| 8 | Set the as-at date and the first plan year's start on the Owners sheet. The test cycle, next operating test due, design check due and test status then calculate. Take every control into the Annual Control Testing Plan by its due date, the "Overdue" ones first. |
| 9 | Name, in 'Audit or review that relies on it', any audit, supervisory review or customer review that will use a control's test. Its test must be final at least [[6]] weeks before that review starts (CA-16). |
| 10 | After every test, update the row from the reviewed workpaper. A Not effective conclusion makes the control Higher until a retest passes; the deficiency goes in the Control Deficiency & Remediation Tracker. |
| 11 | Review the register with each owner at least once a year, and whenever a control, an owner or a risk changes. On the Owners sheet, a control with no owner, or an owner with more key controls than they can keep running, is a finding in itself. |
| 12 | To clear the EXAMPLE, delete the Inventory sheet's rows or its yellow cells once your own register on the Blank inventory sheet is complete. The formulas stay. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Limitations: 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.
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. This register lists what you test and when. It does not show that any control meets a requirement of any framework; which requirement you rely on a control for is your own entry in the Unified Control Framework Mapping Workbook.
Independence: 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. Keep the assurance lead out of the Control owner column.
A failure another control caught is still this control's exception (CA-08). This differs on purpose from P19's MA-05: P19 rates a whole practice with its own checks; P20 tests one control.
EXAMPLE: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, an important entity under NIS2 in its Member State. Its Quality and Compliance Manager, who owns and performs no control here, has led control testing since 1 Sep 2026. A pilot round, TR-2026-P, from 21 Sep 2026 to 25 Sep 2026, tested seven controls over 1 Mar 2026 to 31 Aug 2026, reviewed by its Internal Audit Manager. The register is as at 30 Sep 2026: 5 of 30 controls tested within their cycle, 4 of 5 tested controls effective, and 19 of 24 key controls never tested.
Tailoring for a small organisation: start with the key controls only, and add the rest in the second year. One person may own most controls; the tester must still be someone else, such as a colleague from another function or a contracted tester.
Tailoring for a regulated entity (NIS2, DORA): name, in 'Audit or review that relies on it', the internal audit or independent review that will use the test. The test feeds that audit or review; it is not that audit or review.
This workbook is your own record. Keep it with your test plan and workpapers.
Inventory
EXAMPLE: the 30 controls CT-01 to CT-30, as at 30 Sep 2026. Yellow columns are inputs; white columns calculate against the as-at date on the Owners sheet. Rows at the foot take controls you add.
| Example | Control ID | Control | Control statement: who does what, how often, and the record it leaves (CA-01) | Source pack | Source rule | Source document | Frequency | Occurrences a year | Performer | Record it leaves | Attributes the tester checks on each occurrence | Evidence type | Evidence type (calc) | Control owner | Key control | Risk rating | Why Higher | Rating check (CA-15, calc) | Test cycle in months (calc) | Last test (workpaper) | Last tested period end | Last operating conclusion | Design status | Design last checked on | Design check due (CA-02, calc) | Control started on (if after the plan year began) | Next operating test due (CA-15, calc) | Test status at the as-at date (calc) | Planned in the test plan | Audit or review that relies on it (CA-16) | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | CT-01 | Board report from checked figures | Each quarter, every figure in the board security report comes from one data collection workbook, checked and signed off before the deck is built. | P03 | BR-08 | P03-A05 Board Reporting Data Collection Workbook | Quarterly | 4 | Security reporter | The signed-off data collection workbook and the board deck built from it | • Every figure in the deck appears in the workbook • The workbook was signed off before the deck's date • The sign-off is by someone other than the person who compiled the figures | ET-02 | Review or sign-off | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Dec 2026 | ||||||||
| EXAMPLE | CT-02 | Policy reviews on time | Every policy and standard is reviewed within its tier's interval (12 months for policies and standards, 24 for procedures and guidelines), and sooner on a trigger; a review that changes nothing is still recorded. | P04 | PF-06 | P04-A02 Policy Framework Standard | As it falls due | 12 | Document owner | The policy register's review dates and each review's record | • The review is recorded on or before the due date the register shows • The review was approved at the level the document's tier requires • The register shows the next review date | ET-02 | Review or sign-off | Head of Information Security | Yes | Higher | The board recorded NIS2 measure (h), cryptography, as outstanding until its policy is approved (P12, 30 Jul 2026) | OK | 6 | WP-2026-07 | Not tested | Deficient | 25 Sep 2026 | When the fix is in place (CA-01) | After the design is fixed (CA-01) | Design deficient | Jan 2027 (design); Jul 2027 (retest) | 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. | |||
| EXAMPLE | CT-03 | Joiners acknowledge policies | Each joiner acknowledges the policies that apply to them within 10 working days of starting. | P04 | PF-09 | P04-A02 Policy Framework Standard | As it happens | 120 | HR | The acknowledgement record for each joiner | • Acknowledged within 10 working days of the start date in the HR record • The acknowledgement names the policies and their versions | ET-05 | Training or acknowledgement | HR Director | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Oct 2026 | ||||||||
| EXAMPLE | CT-04 | Quarterly risk review | Each risk owner reviews each of their risks every quarter, and the whole register is reassessed once a year and on any trigger. | P05 | RM-09 | P05-A02 Risk Assessment Methodology & Scoring Model | Quarterly | 48 | Risk owner | Each risk's review date and decision in the register | • The risk was reviewed in the quarter • The review records a decision: rating confirmed or changed, treatment on track or not • The reviewer is the risk owner the register names | ET-02 | Review or sign-off | Head of Information Security | Yes | Standard | OK | 12 | WP-2026-04 | 31 Aug 2026 | Effective | Adequate | 23 Sep 2026 | 23 Sep 2027 | 31 Aug 2027 | In cycle | Jul 2027 | Each of the five sampled reviews was made in its quarter by the owner the register names, with a decision recorded. | |||
| EXAMPLE | CT-05 | Exceptions approved and renewed in time | Every exception is approved by the approver its band sets, runs no longer than its band allows (Low 365 days, Medium 180 days, High 90 days, Critical 30 days), and on expiry is remediated, renewed or escalated within 10 working days. | P02 | EX-05, EX-06, EX-10 | P02-A02 Security Exception & Waiver Standard | As it happens | 10 | Exception approver | The exception register and each exception's request, approval and renewal | • Approved by the approver the band requires, before the exception took effect • Expiry no later than the band allows • On expiry: remediated, renewed or escalated within the grace period | ET-01 | Approval before action | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Oct 2026 | ||||||||
| EXAMPLE | CT-06 | Monthly exception register review | Information security reviews the whole exception register monthly, chasing exceptions near expiry and expired. | P02 | EX-11 | P02-A02 Security Exception & Waiver Standard | Monthly | 12 | Information security | The monthly review record of the exception register | • A review is recorded for the month • Exceptions due to expire within 30 days were chased • Expired exceptions were escalated | ET-02 | Review or sign-off | Head of Information Security | No | Lower | OK | 24 | Not checked yet | Due now | 1 Oct 2028 | Not tested yet | Dec 2026 | ||||||||
| EXAMPLE | CT-07 | Tier 1 suppliers reassessed in time | Each Tier 1 supplier is reassessed at least every 12 months, and on any material change, incident or breach at the supplier. | P06 | TP-09 | P06-A02 Third-Party Security Policy | As it falls due | 14 | Supplier assessor | Each supplier's assessment and decision | • Reassessed within 12 months of the last assessment • The assessment records a decision and who made it • Findings have owners and deadlines | ET-02 | Review or sign-off | Information Security Manager | Yes | Higher | R-02, payment fraud through a compromised supplier email account, is outside appetite (P05) | OK | 6 | Not checked yet | Due now | 1 Apr 2027 | Not tested yet | Nov 2026; May 2027 | |||||||
| EXAMPLE | CT-08 | Metric inputs checked before reporting | Before any figure is reported, its inputs pass the completeness, freshness and plausibility checks, made by someone other than the person who supplied them. | P11 | MR-05, MR-06 | P11-A02 Security Metric Definition & Measurement Method | Monthly | 12 | Metric validator | The data quality log for each reporting cycle | • Each input in the cycle has the three checks recorded • The validator is not the supplier • A failed input was corrected, caveated or withheld | ET-04 | Reconciliation | Head of Information Security | No | Lower | OK | 24 | Not checked yet | Due now | 1 Oct 2028 | Not tested yet | Feb 2027 | ||||||||
| EXAMPLE | CT-09 | NIS2 readiness self-assessed | Readiness for NIS2 is self-assessed at least every 6 months, and after a significant incident or a change in scope, with every item given a readiness level and its evidence. | P12 | NR-08 | P12-A04 NIS2 Readiness Self-Assessment | Every six months | 2 | NIS2 lead | The readiness self-assessment with each item's level and evidence | • Completed within 6 months of the last one • Every item has a level and its evidence • Gaps found are in the gap tracker with owners | ET-02 | Review or sign-off | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Feb 2027 | ||||||||
| EXAMPLE | CT-10 | Board members trained | Every member of the management body follows cybersecurity training at least every 12 months, and a new member within 3 months of appointment, with attendance and content recorded. | P12 | NR-05 | P12-A06 Management Body Cybersecurity Training Plan | As it falls due | 7 | Board secretary | The board training record | • Trained within 12 months of the last training, or 3 months of appointment • Attendance and content recorded | ET-05 | Training or acknowledgement | Board secretary | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | May 2027 | ||||||||
| EXAMPLE | CT-11 | Information register reviewed | Information owners review each register entry at least every 12 months, and review an entry's level within 15 working days of a change to its purpose, users, law, supplier or risk. | P15 | CL-03, CL-12 | P15-A02 Information Classification & Handling Policy | As it happens | 30 | Information owner | The information register's review dates and change reviews | • Entry reviewed within 12 months • A change was reviewed within 15 working days | ET-07 | Register kept current | Head of Information Security | No | Lower | OK | 24 | Not checked yet | Due now | 1 Oct 2028 | Not tested yet | Jun 2027 | ||||||||
| EXAMPLE | CT-12 | Disposal certificates collected | A certificate is kept for every Confidential item a provider sanitises or destroys, received within 10 working days of collection. | P15 | CL-11 | P15-A02 Information Classification & Handling Policy | As it happens | 12 | Records custodian | The disposal record and the provider's certificate | • Every Confidential item collected is on the certificate • Certificate received within 10 working days of collection | ET-03 | Action within a deadline | Head of IT | No | Lower | OK | 24 | Not checked yet | Due now | 1 Oct 2028 | Not tested yet | Next plan year: the second year of its 24-month cycle | ||||||||
| EXAMPLE | CT-13 | Urgent vulnerabilities fixed in time | Priority 1 vulnerabilities are fixed within 7 days of first detection, and Priority 2 within 14 days, counted in calendar days. | P01 | VM-08 | P01-A02 Vulnerability & Exposure Management Standard | As it happens | 70 | Asset owner | The remediation tracker and the scanner's detection and closure dates | • Fixed by the deadline its priority sets, counted from first detection • The fix was confirmed by a rescan • A miss was deferred as an exception before the deadline (P17 PM-14) | ET-03 | Action within a deadline | Head of IT | Yes | Higher | Failed its last test (TR-2026-P) | OK | 6 | WP-2026-02 | 31 Aug 2026 | Not effective | Adequate | 22 Sep 2026 | 22 Sep 2027 | 28 Feb 2027 | In cycle | Feb 2027 (retest); Aug 2027 | Largest customer's supplier security review, 14 Jun 2027: test final by 3 May 2027 (CA-16) | VUL-2026-0301 and VUL-2026-0318 were fixed after their June deadlines, with no deferral requested (P17 PM-14). Two exceptions: Not effective. P19's assessment found the same misses (MP-18). | |
| EXAMPLE | CT-14 | Vendor releases reviewed | Every vendor release that applies to an in-scope system is reviewed within 1 working day of its release, rated with the P01 model and routed to the monthly, expedited or emergency route. | P17 | PM-03 | P17-A02 Patch Management Standard | As it happens | 150 | IT Operations | The release review log | • Reviewed within 1 working day of release • Rated with the P01 model • Routed to a cycle | ET-03 | Action within a deadline | Head of IT | No | Lower | OK | 24 | Not checked yet | Due now | 1 Oct 2028 | Not tested yet | Next plan year: the second year of its 24-month cycle | ||||||||
| EXAMPLE | CT-15 | Missed patch deadlines deferred | A patch that will not be installed by its P01 deadline is deferred as a P02 exception, requested before the deadline passes and approved by the approver its band sets. | P17 | PM-14 | P17-A02 Patch Management Standard | As it happens | 6 | System owner | The deferral request and its approval | • Requested before the deadline • Approved by the band's approver • Expiry no later than the band allows | ET-01 | Approval before action | Head of IT | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Jan 2027 | ||||||||
| EXAMPLE | CT-16 | Leavers' access removed | A leaver's access is removed from every system, including local accounts, by the end of their last working day; for an urgent leaver within 60 minutes of the decision. | P13 | JML-09 | P13-A02 Access Control Policy | As it happens | 80 | System administrator | The provisioning log and each system's account history | • Every account disabled by the end of the last working day in the HR record • Removal recorded in the provisioning log | ET-03 | Action within a deadline | Head of IT | Yes | Standard | OK | 12 | WP-2026-01 | 31 Aug 2026 | Effective | Adequate | 21 Sep 2026 | 21 Sep 2027 | 31 Aug 2027 | In cycle | Mar 2027 | Largest customer's supplier security review, 14 Jun 2027: test final by 3 May 2027 (CA-16) | L-2026-031's ERP account stayed enabled for 19 days after the last working day. The May reconciliation (CT-18) found and disabled it. One exception, so five more leavers were tested (CA-07): none failed. Effective, with the exception recorded and CT-18 noted as having caught it (CA-08). | ||
| EXAMPLE | CT-17 | Movers' old access removed | A mover's old role access is removed on the move date or, with a handover the old manager records, within 5 working days of it. | P13 | JML-08 | P13-A02 Access Control Policy | As it happens | 40 | System administrator | The provisioning log | • Old access removed on the move date, or within the handover window • Any access kept was requested as non-standard | ET-03 | Action within a deadline | Head of IT | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Nov 2026 | ||||||||
| EXAMPLE | CT-18 | Monthly account reconciliation | Within 3 working days of each month end, every in-scope system's accounts are reconciled with the HR record and the sponsor register, and an orphaned account is disabled within 1 working day of being found. | P13 | JML-15 | P13-A02 Access Control Policy | Monthly | 12 | Access coordinator | The reconciliation report and the actions on each difference | • Run within 3 working days of month end • Every in-scope system included • Orphaned accounts disabled within 1 working day | ET-04 | Reconciliation | Head of IT | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Dec 2026 | ||||||||
| EXAMPLE | CT-19 | User access reviews | Access is reviewed at least as often as its scope requires (3 months for privileged access, 6 for systems supporting a critical service, 12 for the rest), and every removal is made within its window (1 working day privileged, 5 standard) and confirmed against a fresh extract. | P07 | AR-02, AR-07 | P07-A02 Access Review Methodology | Every six months | 2 | Campaign coordinator | The campaign's evidence file | • The review covered the system in its interval • Every decision recorded by the reviewer the scope names • Removals made within the window and confirmed against a fresh extract | ET-02 | Review or sign-off | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Mar 2027 | Largest customer's supplier security review, 14 Jun 2027: test final by 3 May 2027 (CA-16) | |||||||
| EXAMPLE | CT-20 | Privileged access reviewed | Privileged access is reviewed every 3 months by the system owner and information security. | P14 | PA-16 | P14-A02 Privileged Access Standard | Quarterly | 4 | System owner with information security | The privileged access review record | • Reviewed within 3 months of the last review • Every privileged account has a decision • Removals made and confirmed | ET-02 | Review or sign-off | Head of IT | Yes | Standard | OK | 12 | WP-2026-06 | Not tested | Adequate | 24 Sep 2026 | 24 Sep 2027 | 21 Sep 2026 | 1 Oct 2027 | Not tested yet | Jan 2027 | 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. | |||
| EXAMPLE | CT-21 | Break-glass accounts tested and every use reviewed | Break-glass accounts are tested every 3 months, alert on every sign-in, and every use is declared and reviewed. | P14 | PA-12 | P14-A02 Privileged Access Standard | Quarterly | 4 | Head of Information Security | The break-glass test and use records | • Tested within 3 months of the last test • Every sign-in in the period was declared and reviewed | ET-06 | Test or exercise | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Apr 2027 | ||||||||
| EXAMPLE | CT-22 | Security induction completed | Each joiner completes the security induction within 10 working days of their start date. | P16 | AW-05 | P16-A02 Annual Security Awareness Plan | As it happens | 120 | Awareness lead | The learning system's completion record | • Completed within 10 working days of the start date in the HR record | ET-05 | Training or acknowledgement | Information Security Manager | Yes | Standard | OK | 12 | WP-2026-03 | 31 Aug 2026 | Effective | Adequate | 23 Sep 2026 | 23 Sep 2027 | 31 Aug 2027 | In cycle | Mar 2027 | Largest customer's supplier security review, 14 Jun 2027: test final by 3 May 2027 (CA-16) | All 20 sampled joiners completed the induction within 10 working days of their start date. | ||
| EXAMPLE | CT-23 | Annual security course completed | Everyone with an account completes the baseline course at least every 12 months. | P16 | AW-04 | P16-A02 Annual Security Awareness Plan | As it falls due | 900 | Awareness lead | The learning system's completion record | • Completed within 12 months of the last completion | ET-05 | Training or acknowledgement | Information Security Manager | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Jul 2027 | ||||||||
| EXAMPLE | CT-24 | Post-incident review held | Every Severity 1 and 2 incident has a post-incident review within 10 working days of closure, with owners and due dates for its actions. | P09 | IM-11 | P09-A02 Security Incident Management Policy | As it happens | 3 | Incident manager | The post-incident review and its actions | • Review held within 10 working days of closure • Every action has an owner and a due date • The risks it touched were sent for reassessment | ET-03 | Action within a deadline | Information Security Manager | Yes | Standard | OK | 12 | WP-2026-05 | 31 Aug 2026 | Effective | Adequate | 24 Sep 2026 | 24 Sep 2027 | 31 Aug 2027 | In cycle | Mar 2027 | Largest customer's supplier security review, 14 Jun 2027: test final by 3 May 2027 (CA-16) | INC-2026-014, closed on 21 Aug 2026, had its review on 27 Aug 2026, four working days later, with an owner and due date for each action; R-04 was reassessed on 20 Aug 2026 (P05). | ||
| EXAMPLE | CT-25 | Incident response exercised | Each audience is exercised at least as often as the audience table sets: every 24 months for board or its equivalent; every 12 months for executive management and the crisis team; every 6 months for incident response team; every 6 months for technical responders; every 12 months for critical suppliers with a part in the plan. | P10 | EX-02 | P10-A02 Tabletop Exercise Design Methodology | As it falls due | 6 | Exercise lead | The exercise programme and each exercise's report | • Each audience exercised within its interval • A live incident was not counted as an exercise | ET-06 | Test or exercise | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Jun 2027 | ||||||||
| EXAMPLE | CT-26 | After-action report approved | The after-action report is approved by the sponsor within 10 working days of the exercise, with every objective rated. | P10 | EX-09 | P10-A12 Exercise After-Action Report Template | As it happens | 3 | Exercise sponsor | The approved after-action report | • Approved within 10 working days • Every objective rated | ET-03 | Action within a deadline | Chief Operating Officer | No | Lower | OK | 24 | Not checked yet | Due now | 1 Oct 2028 | Not tested yet | Next plan year: the second year of its 24-month cycle | ||||||||
| EXAMPLE | CT-27 | Notification readiness checked | The notification readiness checklist is completed at least every 6 months and on any change of authority, channel, signatory or profile, and each signatory's access to each channel is tested at least every 12 months. | P18 | RN-17 | P18-A08 Notification Readiness Checklist | Every six months | 2 | Head of Information Security | The readiness checklist and the channel access tests | • Checklist completed within 6 months • Each signatory's channel access tested within 12 months | ET-06 | Test or exercise | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | May 2027 | ||||||||
| EXAMPLE | CT-28 | Maturity assessed each year | A full maturity assessment runs at least every 12 months. | P19 | MA-17 | P19-A03 Internal Security Assessment Procedure | Annual | 1 | Assessment lead | The assessment report | • Fieldwork ended within 12 months of the last • The lead rated no practice they own or run | ET-02 | Review or sign-off | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Oct 2026 | ||||||||
| EXAMPLE | CT-29 | Supplier High findings escalated | Every supplier finding has an owner and a deadline set by its severity, and a High finding past its deadline is escalated to the business owner. | P06 | TP-08 | P06-A02 Third-Party Security Policy | As it happens | 4 | Supplier relationship owner | The supplier finding log | • Owner and deadline recorded • A High finding past its deadline was escalated | ET-02 | Review or sign-off | Information Security Manager | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Jun 2027 | ||||||||
| EXAMPLE | CT-30 | Triggered risk reassessment | A trigger, such as an incident, a major change or a control failure, forces reassessment of the risks it touches within 10 working days. | P05 | RM-10 | P05-A02 Risk Assessment Methodology & Scoring Model | As it happens | 6 | Risk owner | The reassessment record | • Reassessed within 10 working days of the trigger • The reassessment recorded the trigger | ET-02 | Review or sign-off | Head of Information Security | Yes | Standard | OK | 12 | Not checked yet | Due now | 1 Oct 2027 | Not tested yet | Jun 2027 |
Blank inventory
Your controls. Copy the controls you run from the Inventory sheet, columns B to M, and add your own. Yellow columns are inputs; white columns calculate.
| Example | Control ID | Control | Control statement: who does what, how often, and the record it leaves (CA-01) | Source pack | Source rule | Source document | Frequency | Occurrences a year | Performer | Record it leaves | Attributes the tester checks on each occurrence | Evidence type | Evidence type (calc) | Control owner | Key control | Risk rating | Why Higher | Rating check (CA-15, calc) | Test cycle in months (calc) | Last test (workpaper) | Last tested period end | Last operating conclusion | Design status | Design last checked on | Design check due (CA-02, calc) | Control started on (if after the plan year began) | Next operating test due (CA-15, calc) | Test status at the as-at date (calc) | Planned in the test plan | Audit or review that relies on it (CA-16) | Notes |
|---|
Owners
Owners and counts
Each inventory counted at the as-at date: its controls, ratings and test status, and each owner's controls and key controls. Counts are written "n of m". There is no overall score, no weighting and no percentage (CA-19).
Settings
| As-at date | 30 Sep 2026 | Every test status and count is worked out at this date. EXAMPLE: the quarter end. Type a date, never a formula. |
| First plan year starts on | 1 Oct 2026 | A control never tested is due one test cycle after this date, or after the day it started if later (CA-15). Both inventories read it. |
Inventory counts
| Count | Inventory (EXAMPLE) | Blank inventory (yours) | What it counts | ||||
|---|---|---|---|---|---|---|---|
| Controls in the inventory | 30 | 0 | Every row with a control ID. | ||||
| Key controls | 24 of 30 | Controls answered Yes in Key control. | |||||
| Rated Higher | 3 of 30 | Tested at least every 6 months (CA-15). | |||||
| Rated Standard | 21 of 30 | Tested at least every 12 months (CA-15). | |||||
| Rated Lower | 6 of 30 | Tested at least every 24 months (CA-15). | |||||
| CAM-01 Controls tested within their cycle | 5 of 30 | Controls whose last operating test, concluded Effective or Not effective, covered a period ending within their test cycle, out of the controls in the inventory. Here: next operating test due on or after the as-at date. | |||||
| CAM-02 Tested controls effective | 4 of 5 | Controls whose last operating test concluded Effective, out of the controls tested. | |||||
| CAM-03 Key controls never tested | 19 of 24 | Key controls with no operating test concluded, by name. Name them in the report: filter the inventory on Key control Yes and Test status "Not tested yet" or "Design deficient". | |||||
| Operating test overdue | 0 | 0 | Next operating test due before the as-at date. Put each in the test plan now. | ||||
| Failed their last test | 2 | 0 | Not effective, or design deficient. Each has a deficiency in the Control Deficiency & Remediation Tracker. | ||||
| Rating checks to clear | 0 | 0 | Should be 0. Correct the rating, or the key answer, as the Rating check says. | ||||
| Controls with no owner | 0 | 0 | Should be 0. Every control needs a named owner. | ||||
EXAMPLE, as at 30 Sep 2026: CAM-01 5 of 30; CAM-02 4 of 5; CAM-03 19 of 24. The other headline measures come from the Control Deficiency & Remediation Tracker and the Annual Control Testing Plan.
Owners in the inventory (EXAMPLE)
| Control owner | Controls | Key controls | Rated Higher | Not tested yet | Overdue | Failed last test | What to check |
|---|---|---|---|---|---|---|---|
| Head of Information Security | 14 | 11 | 1 | 13 | 0 | 1 | Fix CT-02 and arrange the retest. |
| HR Director | 1 | 1 | 0 | 1 | 0 | 0 | Agree test dates for the key controls not tested yet. |
| Information Security Manager | 5 | 5 | 1 | 3 | 0 | 0 | Agree test dates for the key controls not tested yet. |
| Board secretary | 1 | 1 | 0 | 1 | 0 | 0 | Agree test dates for the key controls not tested yet. |
| Head of IT | 8 | 6 | 1 | 6 | 0 | 1 | Fix CT-13 and arrange the retest. |
| Chief Operating Officer | 1 | 0 | 0 | 1 | 0 | 0 | Agree a test date in the plan. |
| All owners | 30 | 24 | 3 | 25 | 0 | 2 | The controls total should equal the controls in the inventory, above. |
Owners in the blank inventory (yours)
| Control owner | Controls | Key controls | Rated Higher | Not tested yet | Overdue | Failed last test | What to check |
|---|
| All owners | 0 | 0 | 0 | 0 | 0 | 0 | The controls total should equal the controls in the inventory, above. |
Write each owner once, exactly as in the Control owner column. A total below the controls in the inventory means a control has an owner not listed here, or none.
Risk rating guide
Risk rating guide
How often each control is tested depends on its risk rating. Decide first whether it is key, then rate it. The inventories read the yellow cycles below.
The ratings and their test cycles (CA-15)
| Rating | Test cycle (months) | When it applies | Sample size column (CA-05) |
|---|---|---|---|
| Higher | 6 | A key control on which a risk outside appetite, or an obligation the organisation has recorded as not met, rests; or a control that failed its last test. | The Higher column |
| Standard | 12 | Any other key control. | The Standard column |
| Lower | 24 | A control that is not key. Its design is still checked every 12 months (CA-02). | The Standard column |
| Months between design checks, for every control (CA-02) | 12 | A design is also checked whenever the control changes, and before its first operating test. |
Is it a key control?
A control whose failure, on its own, would let a risk on the register happen or go unnoticed, or that the organisation names as its evidence for an obligation. Key controls are never rated Lower risk.
Question
Question 1
Question 2
Yes to either: the control is key. No to both: it is not.
Giving the rating, step by step
| Ask | If yes | If no | |
|---|---|---|---|
| Did the control fail its last test? | Higher, until a retest passes (CA-15). Record the test in 'Why Higher'. | Go to the next question. | |
| Is it a key control? Use the two questions above. | Go to the next question. | Lower. Its design is still checked every [[12]] months (CA-02). | |
| Does a risk outside your appetite rest on it, or an obligation your organisation has recorded as not met? | Higher. Name the risk or the obligation in 'Why Higher'. | Standard. | |
EXAMPLE: why three controls are Higher
| Control | Why Higher | Owner | |
|---|---|---|---|
| CT-02 Policy reviews on time | The board recorded NIS2 measure (h), cryptography, as outstanding until its policy is approved (P12, 30 Jul 2026) | Head of Information Security | |
| CT-07 Tier 1 suppliers reassessed in time | R-02, payment fraud through a compromised supplier email account, is outside appetite (P05) | Information Security Manager | |
| CT-13 Urgent vulnerabilities fixed in time | Failed its last test (TR-2026-P) | Head of IT | |
A Higher control is tested twice in the plan year. The EXAMPLE's 6 controls that are not key are all Lower.
The rules the ratings follow
Rule
CA-02
CA-15
Adding your own controls
Adding your own controls
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.
Steps
| Step | What to do | ||
|---|---|---|---|
| 1 | Check the control is not already in the set under another name. Two rows for one control means two tests of the same thing. | ||
| 2 | Write the statement in the form CA-01 asks for: who does it, what they do, how often, and the record it leaves. If you cannot name the record, the control cannot be tested yet: that is a design deficiency, not a missing detail. | ||
| 3 | Name the rule it comes from: your own policy or standard, by its ID and section. A control with no written rule behind it has nothing to be tested against. | ||
| 4 | List the attributes: the two or three things a tester will check on every occurrence. Each one is a yes or no question about one occurrence, such as "approved before the change". | ||
| 5 | Choose the evidence type from the table below. It tells the tester what an acceptable record looks like. | ||
| 6 | Name the owner, decide whether it is key, and give it a rating with the guide on the previous sheet. Give it the next free ID, CT-31 onward, and never reuse an ID. | ||
| 7 | Ask the assurance lead to walk one occurrence through from start to record before the control's first operating test (CA-02). Record the design status. | ||
A statement in four parts: CT-16 as the model
| Part | CT-16 | Yours | |
|---|---|---|---|
| Who does it | System administrator | [[the role that carries it out]] | |
| What they do | A leaver's access is removed from every system, including local accounts, by the end of their last working day; for an urgent leaver within 60 minutes of the decision. | [[the action, with its deadline]] | |
| How often | As it happens | [[as it happens, monthly, quarterly...]] | |
| The record it leaves | The provisioning log and each system's account history | [[the system or file the tester will read]] | |
| The rule it comes from | P13 JML-09, in the Access Control Policy | [[your policy or standard, its ID and section]] | |
| The attributes a tester checks | Every account disabled by the end of the last working day in the HR record; Removal recorded in the provisioning log | [[two or three yes or no checks on one occurrence]] | |
The evidence types
| Evidence type | Kind of control | Examples | |
|---|---|---|---|
| ET-01 | Approval before action | Access requests, exception requests, changes | |
| ET-02 | Review or sign-off | Risk reviews, access reviews, policy reviews, register reviews | |
| ET-03 | Action within a deadline | Leaver removals, fixes within deadline, reviews after an incident | |
| ET-04 | Reconciliation | Monthly account reconciliation, metric data checks | |
| ET-05 | Training or acknowledgement | Security induction, annual course, policy acknowledgement, board training | |
| ET-06 | Test or exercise | Break-glass tests, exercises, readiness checks | |
| ET-07 | Register kept current | Information register, end-of-life register, supplier register | |
| ET-08 | System setting | Automated controls (CA-09) | |
What acceptable evidence looks like for each type, and what is not acceptable, is in the Control Evidence Standards Checklist.
Restore testing
Restore testing is not in this set. The Cyber Resilience & Recovery pack sets the recovery test of each critical service, restoring its data, at least every 12 months (RR-14), and the Backup & Restore Assurance pack's Restore Testing Methodology sets the other restore checks. Add a control here quoting the rule you rely on: for example, who restores what, from which backup, how often, and the record of the result.
Lists
| Frequency | Risk | YesNo | Conclusion | Design | EvidenceID | EvidenceName |
|---|---|---|---|---|---|---|
| As it happens | Higher | Yes | Effective | Adequate | ET-01 | Approval before action |
| As it falls due | Standard | No | Not effective | Deficient | ET-02 | Review or sign-off |
| Monthly | Lower | Not tested | Not checked yet | ET-03 | Action within a deadline | |
| Quarterly | ET-04 | Reconciliation | ||||
| Every six months | ET-05 | Training or acknowledgement | ||||
| Annual | ET-06 | Test or exercise | ||||
| ET-07 | Register kept current | |||||
| ET-08 | System setting |
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Control | Something done routinely to keep a risk in check, written as who does what, how often, and the record it leaves (CA-01). |
| Key control | A control whose failure, on its own, would let a risk on the register happen or go unnoticed, or that the organisation names as its evidence for an obligation. Key controls are never rated Lower risk. |
| Control owner | The manager accountable for a control running and leaving its record. Agrees test dates, provides access to records and fixes deficiencies. |
| Performer | The person who carries out the control each time it runs. May not test it (CA-10). |
| Tester | The person who tests a control. Owns and performs none of the controls they test (CA-10). |
| Attribute | One thing the tester checks on every sampled occurrence, such as "removed by the end of the last working day" or "approved before the change". Each control's attributes are listed with it. |
| Design check | A check that the control, as written and as set up, would prevent or detect the risk if it ran: a walkthrough of one occurrence from start to record (CA-02). |
| Operating test | A check, on a sample chosen by the tester, that the control ran as designed throughout the testing period (CA-04 to CA-07). |
| Testing period | The months the operating test covers: since the control was last tested, and never longer than its test cycle (CA-06). |
| Retest | An operating test of a fixed control, made after it has run enough times to sample, by someone other than its owner. A deficiency closes only on a retest that passes (CA-14). |
| Workpaper | The record of one test: population and its source, sample, attributes, results, exceptions, conclusion, tester and reviewer (CA-11). |
| Control assurance lead | The person who runs control testing: keeps the inventory and the plan, assigns testers, reviews workpapers, and rates deficiencies. Owns and performs no control in scope. |
| Higher risk | A key control on which a risk outside appetite, or an obligation the organisation has recorded as not met, rests; or a control that failed its last test. Tested at least every [[6]] months. |
| Standard risk | Any other key control. Tested at least every [[12]] months. |
| Lower risk | A control that is not key. Its design is still checked every 12 months (CA-02). Tested at least every [[24]] months. |
| Effective | The last operating test found no exception, or one exception and none in the added sample (CA-07). |
| Not effective | The last operating test failed. The control is Higher risk until a retest passes (CA-15). |
| Not tested | The control was examined, but had not yet run in the period, or its design was deficient (CA-01, CA-06). It counts as never tested. |
| Test cycle | The longest time between the end of one tested period and the end of the next, in months, from the control's risk rating (CA-15). |
| Next operating test due | The end of the last tested period plus the test cycle: the date by which the next test's period must end. For a control with no operating test concluded, the start of the first plan year, or the day the control started if later, plus the test cycle (CA-15). "After the design is fixed (CA-01)": fix the design first. |
| Design check due | The date the design was last walked through plus [[12]] months (CA-02). "Due now": never walked through. |
| Test status | "In cycle": next test due on or after the as-at date. "Overdue": due before it. "Not tested yet": no operating test concluded. "Design deficient": operation not tested until the design is fixed. |
| As-at date | The date the test status and every count are worked out at. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| CT-nn, CA-nn, ET-nn, CAM-nn | The controls, rules, evidence types and headline measures of the Control Testing Methodology. A source rule such as P13 JML-09 is the rule of that pack's published document. |
| EXAMPLE | A worked example: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, as at 30 Sep 2026. Delete before use. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 5.36 — Compliance with policies, rules and standards for information security | Inventory sheet: the controls whose compliance with the organisation's policies and standards is reviewed, with the test cycle for each |
| ISO/IEC 27001:2022 | Clause 6.1.3 — Information security risk treatment | Inventory sheet: the controls that carry out the risk treatment, each with its owner, its risk rating and the risk it rests on for a Higher control |
| NIST CSF 2.0 | ID.IM-01 — “Improvements are identified from evaluations” | Inventory and Owners sheets: which controls are evaluated, when, and what the last evaluation found, so improvements can be identified from them |
| NIS2 — Directive (EU) 2022/2555 | Article 21(2)(f) — “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” | Inventory sheet: the list of measures whose effectiveness is assessed, each with its owner, its test cycle and its last result. The procedures that assess them are in the Control Testing Methodology and the Control Test Execution Procedure |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | Applies only to the providers its Article 1 names. For them, the Annex point below; for others, a useful guide |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 2.2.1 — regularly review compliance with the network and information system security policies, topic-specific policies, rules and standards; “The management bodies shall be informed of the status of network and information security on the basis of the compliance reviews by means of regular reporting.” | Inventory and Owners sheets: what is reviewed and when, by owner, so that compliance with policies and standards is reviewed regularly. For the providers Article 1 names, the results can feed the report to the management body; the register is not that report |
| DORA — Regulation (EU) 2022/2554 | Article 6(3) — financial entities minimise the impact of ICT risk through appropriate strategies, policies, procedures, ICT protocols and tools, and “shall provide complete and updated information on ICT risk and on their ICT risk management framework to the competent authorities upon their request” | Inventory sheet, for financial entities: an up-to-date list of the controls in the ICT risk management framework, with owners and test results, ready to give the competent authority on request |
| DORA — Regulation (EU) 2022/2554 | Article 6(5) — the ICT risk management framework is documented and reviewed at least once a year (periodically for microenterprises), upon major ICT-related incidents, and following supervisory instructions or conclusions from digital operational resilience testing or audit processes; “It shall be continuously improved on the basis of lessons derived from implementation and monitoring.” A report on the review is submitted to the competent authority on request | Owners sheet, for financial entities: the controls tested, not yet tested and failed, which can inform the yearly review of the ICT risk management framework. It does not replace the internal audit of that framework |
| GDPR — Regulation (EU) 2016/679 | Article 5(2) — “The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’).” | Inventory sheet: a record of which controls exist, who owns them and when each was last shown to work, which helps a controller demonstrate its measures |
| GDPR — Regulation (EU) 2016/679 | Article 24(1) — the controller implements appropriate technical and organisational measures to ensure, and to be able to demonstrate, that processing is performed in accordance with the Regulation; “Those measures shall be reviewed and updated where necessary.” | Inventory sheet: the measures listed with their review dates, so they are reviewed and updated where necessary |
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.
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard.