A control that has never been tested is an assumption, and auditors, regulators and attackers all treat it that way. Most teams can list their controls, but far fewer can show a written plan that says which controls are tested, how, by whom, against what population and with what pass criteria. This template is that plan. It separates test of design from test of operating effectiveness, fixes the method and evidence for each test, sets rules for sampling, deviations and retesting, and produces results that feed a remediation log. It is written for control owners, second line risk teams and internal auditors who need a repeatable plan for an annual or continuous testing cycle. The reasoning behind effectiveness measurement sits in the Measuring security control effectiveness guide; this page is the working document.
How to use this template
- Replace the placeholders: text in square brackets, such as [Organisation], [Testing Lead], [Control Owner] and [X days], is yours to set. Keep the section numbers so findings can reference them.
- Start from your control library: the plan tests controls, not frameworks. If you run one control set mapped to several frameworks, test each control once and reuse the result. See the Common Control Framework Template.
- Write the test before you collect the evidence: a test step written after the evidence arrives tends to describe whatever the evidence shows.
- "Must" is mandatory; "should" is recommended: any departure from a "should" needs a recorded reason in the test file.
- Keep the plan and the results separate: the plan is approved before fieldwork; results are recorded per test in the worksheet in section 8.
1. Purpose
1.1 This plan sets out how [Organisation] tests whether its security controls are designed to meet their objectives and operate as designed throughout the period [Period start] to [Period end].
1.2 It provides evidence for [management assertions / ISO/IEC 27001 internal audit / SOC 2 readiness / SOX IT general controls / regulator reporting], and identifies deficiencies early enough to fix them before external assessment.
2. Scope
2.1 In scope are the controls listed in the control testing register (Appendix A), drawn from [control library name and version], covering the systems, sites and services below:
- Systems: [in-scope applications, cloud accounts, identity providers, network segments].
- Identity populations: workforce users, privileged accounts, and non-human identities (service accounts, API keys, workload identities and AI agents). Access controls must be tested against every population they claim to cover.
- Third parties: [outsourced providers whose controls [Organisation] relies on, with the assurance report used, for example a SOC 2 Type 2 report].
2.2 Out of scope: [list], with the reason and the risk owner who accepted the exclusion.
2.3 Testing must not change production data or weaken a control. Any test that exercises a live control (for example a benign detection trigger) must be approved under section 6.4.
3. Roles and responsibilities
| Role | Responsibilities | Independence requirement |
|---|---|---|
| [Plan Owner], for example the CISO or Head of GRC | Approves the plan, scope and risk ratings; accepts residual risk on unresolved deficiencies | None |
| [Testing Lead] | Schedules tests, assigns testers, reviews every test file, signs off conclusions | Must not own any control in the cycle they lead |
| Testers | Write and perform tests, record evidence, raise deviations | Must not test a control they operate or designed |
| [Control Owner] | Provides populations and evidence by the agreed date, agrees the factual accuracy of findings, owns remediation | Not applicable |
| Reviewer (second tester or quality reviewer) | Re-performs a sample of [X]% of completed tests and all failed tests | Must not have performed the test reviewed |
| [Internal Audit] | May rely on this plan's work after assessing tester competence and objectivity | Independent of the first and second line |
4. Test approach
4.1 Test of design (ToD). Each control must first be assessed for design: whether, if it operated as described by a competent and authorised person or system, it would meet its control objective and address the risk it is mapped to. Design is assessed through a walkthrough, following one real instance end to end, with inquiry, observation and inspection of the configuration or record. PCAOB AS 2201 describes design testing and walkthroughs in these terms (paragraphs .37 to .43).
4.2 Test of operating effectiveness (ToE). Controls rated as effectively designed must then be tested to show they operated as designed across the period and that the performer had the authority and competence to perform them (AS 2201 paragraphs .44 and .45). A control that fails ToD must not be tested for ToE; it is reported as a design deficiency.
4.3 Methods. Testers must use the assessment methods defined in NIST SP 800-53A Rev. 5: examine (review, inspect, observe, study or analyse assessment objects), interview (discussions with individuals or groups) and test (exercise assessment objects under specified conditions). Within those, the techniques below apply.
| Technique | What it proves | Use it for | Limit |
|---|---|---|---|
| Inquiry (interview) | How the control is meant to work | Understanding the control; never as sole evidence | AS 2201 .50 states that inquiry alone does not provide sufficient evidence |
| Observation | The control ran on the day observed | Manual controls, physical controls, live walkthroughs | Point in time; the performer knows they are watched |
| Inspection (examine) | A record or setting exists and shows the control acted | Approvals, review sign-offs, configuration exports, logs | A record can exist without a real review behind it |
| Re-performance | The tester gets the same result as the control | Leaver reconciliations, access review completeness, backup restores | Labour-intensive; usually sampled |
| Automated full-population test | Every item in the population met the rule | Configuration baselines, MFA coverage, key rotation age, dormant accounts | Only as reliable as the data source and the script, which must themselves be validated |
| Benign trigger or test transaction | A preventive or detective control fires on a harmless condition | Detection rules, data loss prevention, email filtering, canary credentials | Proves the simple path only; see the Detection Validation and Testing Guide |
4.4 Depth and coverage. For each control the plan must record a depth (basic, focused or comprehensive) and a coverage (basic, focused or comprehensive), the attribute values used in SP 800-53A. Controls rated high risk in section 5 must be tested at focused depth or above.
4.5 Evidence strength. Prefer system-generated evidence over screenshots, and re-performance or full-population testing over inspection. Evidence must show date, system and population; a screenshot without a visible timestamp and system identifier is not accepted.
5. Risk rating and test frequency
5.1 Each control in Appendix A must carry a risk rating that drives depth, sample size and frequency. The ratings and frequencies below are defaults; [Organisation] may tighten them.
| Control risk rating | Typical examples | Minimum test frequency | Minimum depth |
|---|---|---|---|
| High | Privileged access, MFA enforcement, secrets and key rotation, backup restore, change approval for production | [Annually ToD; ToE every 6 months or continuous automated test] | Focused or comprehensive |
| Medium | Joiner and leaver processing, vulnerability remediation within SLA, logging coverage, vendor access | [Annually ToD and ToE] | Focused |
| Low | Policy publication, awareness completion, asset labelling | [ToD annually; ToE every 2 years] | Basic |
5.2 Risk factors that raise a rating: the control is the only one addressing a risk; it covers privileged or non-human identities; it is manual; it changed in the period; or it failed the previous cycle.
6. Populations, sampling and timing
6.1 Population completeness. Before sampling, the tester must confirm the population is complete by reconciling it to an independent source (for example HR leavers against identity provider disablement events, or the cloud asset inventory against the endpoint agent list). Record the source, extraction query, date and row count.
6.2 Sample sizes. Where a full-population automated test is not possible, sample sizes must follow [Organisation's sampling methodology or the external auditor's table], based on control frequency (for example annual, quarterly, monthly, weekly, daily, many times a day) and risk rating. Samples must be selected randomly or systematically across the whole period, never chosen by the control owner.
6.3 Timing and roll-forward. Tests performed before period end at an interim date must be updated with roll-forward evidence that the control did not change. Where the risk of change is low, AS 2201 (paragraph .56) allows inquiry alone for the roll-forward; otherwise re-test a sample from the remaining period.
6.4 Live control testing. Tests that exercise a production control (benign triggers, failover, restore tests, simulated phishing) need written approval from [Control Owner] and [Change Authority], a defined window, a stop condition and a rollback step. Penetration testing and red teaming follow their own rules of engagement under a separate plan.
7. Test procedure record
7.1 Each control in Appendix A must have a test procedure with the fields below, written and approved before fieldwork.
- Control ID and statement: as in the control library, with owner and frequency.
- Control objective and risk: what the control prevents or detects.
- Framework references: for example NIST SP 800-53 AC-2, ISO/IEC 27001:2022 Annex A control, CIS Controls v8.1 safeguard.
- Test type: ToD, ToE or both; manual or automated.
- Method and steps: numbered steps another tester could repeat and reach the same result.
- Population and source: as in 6.1.
- Sample size and selection method: as in 6.2.
- Pass criteria: written as a measurable attribute, for example "every privileged role assignment in the sample has an approved ticket dated on or before the assignment".
- Evidence required: named report, export or log, with file naming convention [ControlID_TestID_Date].
- Tester, reviewer and dates.
8. Results, deviations and deficiencies
8.1 Each test must conclude one of: Effective, Effective with exceptions (deviations within the tolerance set in the procedure, with a recorded root cause), or Not effective.
8.2 A deviation is a sampled item that failed the pass criteria. On any deviation the tester must: record the item and the cause; decide with the Testing Lead whether to extend the sample by [X] items; and consider whether a compensating control addresses the same risk. A compensating control may only be relied on if it is itself tested.
8.3 Deficiencies must be rated [Low / Medium / High / Critical] using likelihood and magnitude, logged in [remediation tracker] with an owner and due date, and tracked to closure. For financial reporting controls, use the deficiency, significant deficiency and material weakness categories defined in AS 2201. See Audit Exception vs Control Deficiency.
8.4 A remediated control must be retested after it has operated for [a minimum period or number of instances] before the deficiency is closed. Closing on the strength of a new policy or a single instance is not permitted.
| Worksheet field | Example entry |
|---|---|
| Control ID | [IAM-07] Quarterly privileged access review |
| Test ID and type | [T-IAM-07-ToE-Q3], operating effectiveness, re-performance |
| Population | [42] privileged role holders, human and non-human, from the PAM vault and identity provider, reconciled on [date] |
| Sample | [2] of [4] quarterly reviews, all items re-performed |
| Result | Effective with exceptions: [1] service account not in review scope |
| Deficiency reference | [DEF-2026-031], Medium, owner [IAM Lead], due [date] |
9. Reporting
9.1 The Testing Lead must issue a report within [X working days] of fieldwork closing, showing: controls planned, tested, deferred and why; results by control and by risk rating; deficiencies by severity and age; repeat findings; and any scope limitation.
9.2 Results feed the risk register and the plan of action and milestones (NIST SP 800-53 CA-5) where one is kept. Continuous automated tests report on the cadence set in [continuous monitoring strategy], consistent with CA-7.
10. Framework alignment
| Framework | Reference | How this plan supports it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CA-2 Control Assessments; CA-5 Plan of Action and Milestones; CA-7 Continuous Monitoring | Assessment plan, results and remediation tracking |
| NIST SP 800-53A Rev. 5 | Assessment methods, depth and coverage | Sections 4.3 and 4.4 |
| NIST CSF 2.0 | GV.OV-03; ID.IM-02 | Performance review and improvement from tests |
| ISO/IEC 27001:2022 | Clause 9.1 monitoring and measurement; clause 9.2 internal audit; Annex A 5.35 and 5.36 | Evidence of control monitoring and independent review |
| PCAOB AS 2201 | Paragraphs .42 to .56 | Design and operating effectiveness, nature, timing and extent |
| IIA Cybersecurity Topical Requirement | Effective 5 February 2026 | Baseline for internal audit assessment of cyber controls |
11. Approval and review
11.1 This plan is approved by [Plan Owner] before fieldwork and reviewed at least annually, after any significant change in systems or control library, and after any Not effective result on a high-risk control.
11.2 Version: [1.0]. Approved by: [name, role]. Date: [date]. Next review: [date].
Implementation guidance
- Automate the high-volume tests first. MFA coverage, key and secret age, dormant accounts and configuration baselines suit full-population scripted tests, which replace sampling and can run continuously. See the Audit Evidence and Continuous Controls Monitoring Guide.
- Test non-human identities explicitly. Access reviews and leaver controls written for people routinely skip service accounts, tokens and agents. Add them to the population in 6.1 and the pass criteria in 7.1. See the Access Reviews Guide.
- Common failure patterns. Populations supplied by the control owner and never reconciled; screenshots with no date; tests that only restate the procedure document; ToE performed on a control that failed design; deficiencies closed on a policy update; and the same person designing, operating and testing a control.
- Measure the programme. Track the share of high-risk controls tested in cycle, the share tested by automation, deficiencies open beyond due date, repeat findings and the rate at which reviewer re-performance overturns a tester conclusion.
- Coordinate with external assurance. Agree sample methodology and evidence standards with the external auditor or assessor up front; FedRAMP, for example, publishes its own Security Assessment Plan template for third-party assessors. Align so they can rely on your work.
- Track findings to closure. See the Audit Finding Remediation Guide and the Audit Evidence Request Tracker Template.
Standards and references
- NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls in Information Systems and Organizations
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- PCAOB: AS 2201, An Audit of Internal Control Over Financial Reporting
- NIST: Cybersecurity Framework 2.0
- The IIA: Cybersecurity Topical Requirement
- FedRAMP: Documents and Templates, Security Assessment Plan and Report
Related NHI Mgmt Group resources: Measuring security control effectiveness · Common Control Framework Template · Internal Audit for Cybersecurity Guide · How to Read a SOC 2 Report Guide