Control testing and ITGC

Scope: controls that must be shown operating · Who: the officer answering for the control set · Prerequisites: a control catalogue with owners and evidence · First result: one week

1. Why this exists (the failure mode it prevents)#

A screenshot of a setting, taken on one day, proves the setting was that way on that day. It proves nothing about the eleven months either side. Yet it is what most organisations mean by a tested control.

Four things go wrong together. The population is never established, so nobody can show the twenty tickets sampled came from a complete list. The sample is chosen by whoever was free that afternoon. An exception is argued away rather than evaluated and written down. And the general controls under every application control are discovered as a category only when the auditor asks for a year of change tickets.

The failure surfaces in predictable wording. Clause 9.1 is titled Monitoring, measurement, analysis and evaluation ¹. Clause 9.2 requires a planned internal audit programme, with auditors chosen so objectivity and impartiality are preserved ². On the attestation side, criterion CC4.1 concerns running ongoing and separate evaluations, to establish whether each part of the internal control system is in place and working. Criterion CC4.2 concerns evaluating deficiencies and communicating them promptly to those responsible for corrective action ³.

The period cannot be recovered late. The criteria document describes a type 2 SOC 2 engagement as opining on both how controls are designed and how they ran across a stated period. It adds a description of the auditor's tests and results. A type 1 engagement covers the same ground. Its report carries neither that opinion nor the description of tests ⁴.

Three disciplines meet in one test. Governance owns the control and signs the conclusion, so the sign-off names a role. Risk sets how much testing the control earns, since depth and frequency follow the risk it treats. Compliance is the workpaper, the record letting a second person repeat the test. One loop, not three functions filing separately.

2. Definitions (only the ones that cause disputes)#

Eight terms decide whether a result means anything. Where a term is GRCIDE's own the table says so, and those are not requirements of any standard.

Term	Working definition	Source
Control test	A procedure establishing whether a control did what it was designed to do, over a stated period and sample.	GRCIDE working definition, against clause 9.1 1
Test of design	A test asking whether the control, as built, would prevent or detect what it exists for.	GRCIDE working definition. The criteria document pairs design with how the control actually ran 5
Test of operating effectiveness	A test asking whether the control ran as designed throughout the period, on a sample from a complete population.	GRCIDE working definition
ITGC	GRCIDE's shorthand for the general controls over technology that application controls lean on: access, change, operations, backup and recovery.	GRCIDE working definition. Criterion CC5.2 concerns general control activities over technology 6
Population, and its completeness check	Every occurrence of the control in the period, from a named source system, with boundaries stated. The completeness check is the reconciliation showing it is the whole population.	GRCIDE working definitions
Sample	The subset examined. Audit evidence should be verifiable and is generally based on samples, since an audit runs in finite time and resources.	ISO 19011:2018 clause 4 7
Exception, finding	An exception is one sampled item where the control did not operate. A finding is what it becomes once accepted as a weakness.	GRCIDE working definitions. Control 5.36 expects causes identified and corrective actions reviewed for effectiveness 8
Procedure type	Inquiry, observation, inspection and re-performance: four ways a tester obtains evidence.	GRCIDE working definitions, not drawn from any attestation standard

Evidence keeps the auditing standard's sense: records, statements of fact and other information relating to the criteria, which can be verified ⁹.

3. The method — numbered steps, each with input, activity, output and owner#

Ten steps. The first three fix what is tested; the next three fix depth, procedure and record; the last four handle exceptions, the calendar, automation and the auditor.

3.1 Draw the ITGC map before testing anything#

General controls come first because everything else inherits from them. If access to the payment platform is uncontrolled, the reconciliation control inside it proves nothing. Criterion CC5.2 carries a point of focus on that dependency. It links a business process and its automated controls to the general controls beneath ⁶.

Domain	What runs in it	ISO/IEC 27002:2022	Criteria
Access	Joiners, movers, leavers; privileged access; access review; authentication	8.2 Privileged access rights; 8.3 Information access restriction; 8.5 Secure authentication	CC6.1, CC6.2, CC6.3
Change	Authorisation; test before release; approval; deployment separation; emergency and patch routes	8.32 Change management; 8.31 Separation of development, test and production environments; 8.19 Installation of software on operational systems	CC8.1
Operations	Configuration baselines; logging; monitoring; vulnerability cycles	8.9 Configuration management; 8.15 Logging; 8.16 Monitoring activities; 8.8 Management of technical vulnerabilities	CC7.1, CC7.2
Backup and recovery	Backup coverage; restore testing; recovery exercises	8.13 Information backup	A1.2, A1.3 (availability only)

Two reference controls anchor the change domain. Control 8.32 expects every change to an information processing facility or system to pass through change management procedures ¹⁰. Control 8.31 expects development, testing and production environments to be separated and secured ¹¹. Criterion CC8.1 covers the same ground: authorising, configuring, documenting, testing, approving and implementing change to infrastructure, data, software or procedure ¹².

The backup domain sits apart. Criterion A1.2 concerns backup processes and recovery infrastructure; A1.3 concerns testing the recovery plan procedures supporting system recovery ¹³.

• Input: the control catalogue; the system inventory; the criteria in scope.
• Activity: list the systems in scope; assign each control to one domain; mark the application controls depending on each.
• Output: ITGC map, one page per domain, with the dependencies named.
• Owner: the officer who owns the control set; platform owners confirm.

3.2 Make each control testable before writing the test#

A control is testable when three things are written down: the attribute a tester can observe, the record carrying it, and the frequency it should appear at. Without the first, the tester invents a criterion at the desk. Without the second, the test becomes an interview.

The plan itself is not written here. Control ownership and the control catalogue produces the test plan at its section 3.6. This playbook starts where that row exists and runs it. Reference control 5.36 expects compliance with the policy set, rules and standards to be regularly reviewed, with results and corrective actions recorded ⁸.

• Input: the test plan row; the evidence schedule; the control objective.
• Activity: name the observable attribute and its record; confirm the frequency matches what the control does.
• Output: test objective, one sentence, written before evidence is requested.
• Owner: the control owner supplies the attribute; assurance writes the objective.

3.3 Establish the population, then prove it is complete#

The population is every occurrence of the control in the period. Three fields make it inspectable: the source system, the query, and the boundaries. A population with no stated boundary is a list.

Completeness is proved by reconciliation, not asserted. Reconcile the export's count against an independent count in the source system, check the first and last records against the boundaries, and compare the total against a second system.

A reconciliation needs something to reconcile to. Control 8.9 expects hardware, software, service and network configurations, security settings among them, to be established and documented, then implemented, monitored and reviewed ¹⁴. Control 8.15 expects logs of activity, exceptions, faults and other notable events to be produced, stored, protected and analysed ¹⁵.

• Input: the test objective; the source system; the period start and end.
• Activity: extract the population; record the query and boundaries; run a reconciliation and record its outcome either way.
• Output: population record: source, query, boundaries, size, check.
• Owner: the tester; the system owner countersigns the extraction.

3.4 Set the sample from risk, and say how it was chosen#

Sampling is a method choice. The auditing standard's evidence-based principle ties the appropriate use of sampling closely to the confidence the conclusions can carry ⁷. Depth follows risk. Criterion CC4.1 carries a point of focus: risk decides how wide a separate evaluation is, and how often it runs ¹⁶.

The table below is GRCIDE's house practice; no standard named here sets sample sizes. Adjust up for a high risk, an exception last period, a changed operator, or a fully manual control.

Control frequency	Population over twelve months	House sample
Annual	1	1
Quarterly	4	2
Monthly	12	3
Weekly	52	8
Daily	around 250	25
Continuous or event-driven	thousands	25 to 40, risk-weighted

Selection method decides what the result supports. Random selection, the default, supports a statement about the population. Systematic selection, every nth item, is acceptable where the ordering carries no bias. Judgemental selection tests the worst case and supports no statement about the rest, so it supplements rather than replaces. Where size comes from appetite instead of the table, the reasoning belongs with the risk decision — see risk appetite and criteria.

• Input: the population record; the risk the control treats; the frequency.
• Activity: set the size from the table or record the departure; record the selection method; keep the drawn list.
• Output: sample record: size, method, drawn items, any departure.
• Owner: the tester; the assurance function approves departures.

3.5 Choose the procedure type the control actually needs#

The four procedure types are GRCIDE's working vocabulary, not a citation from any attestation standard. They differ in what they prove.

• Inquiry — asking the operator how the control runs. It orients the tester and proves nothing alone.
• Observation — watching the control run. It proves the control can run, at that moment.
• Inspection — examining the records produced. The workhorse: records carry dates, and dates cover the period.
• Re-performance — repeating the control and comparing. Strongest and dearest, kept for material controls.

Most tests combine two: inquiry to understand, then inspection across the sample. Independence is not optional. Reference control 5.35 expects the approach to managing information security to be reviewed independently at planned intervals. The reviewer is independent of the area under review and outside its line of authority ¹⁷. The auditing standard asks for objectivity, so conclusions rest only on the evidence ⁷.

• Input: the test objective; the sample; the evidence available.
• Activity: pick the procedure type and record why; never let inquiry stand alone; assign a tester who does not operate the control.
• Output: procedure statement in the workpaper, naming type and reason.
• Owner: the assurance function.

3.6 Write the workpaper so a second person can re-perform the test#

The workpaper is the deliverable. Everything above exists to fill it, and a test is only as good as the document that outlives the tester.

Eight fields let a second person repeat the work. The control and the criterion it answers. The test objective. The population with its completeness check. The sample with its selection method. The procedure type. The evidence, by record name. The conclusion, with tester and reviewer roles. The control test workpaper ships those fields, with an exceptions sheet and a calendar beside them.

Two rules keep it honest. Name records, not systems, and write the conclusion about the period rather than the day. Clause 7.5 covers documented information, with 7.5.3 titled Control of documented information ¹⁸.

• Input: the population, sample, procedure and evidence records.
• Activity: fill every field; reference each record by name; have a second role review before signing.
• Output: control test workpaper, one per control per test cycle.
• Owner: the tester writes it; the reviewer signs; the owner signs the conclusion.

3.7 Evaluate an exception instead of arguing with it#

An exception is a fact about one sampled item. What it means for the conclusion is a separate judgement, and merging the two is how exceptions get talked away.

Four questions settle it. Is it isolated or systemic, judged from the cause rather than the count? Does a compensating control cover the same risk over the same period? What is the effect on this control's conclusion? What is the root cause? Remediation follows, then a re-test inside the period wherever possible. Criterion CC4.2 carries points of focus on assessing results and communicating deficiencies. It also covers tracking whether they are remedied on a timely basis ¹⁹.

Two exits, not interchangeable. A weakness carried to closure is a finding, tracked in the findings-to-closure tracker; clause 10.2 is Nonconformity and corrective action ²⁰. Residual risk knowingly carried is an acceptance — see risk acceptance and residual risk. An exception is a risk event before it is a finding, and the register learns of it either way.

• Input: the exception as found; the sample record; the register entry.
• Activity: classify isolated or systemic; test any compensating control; state the cause; set remediation, owner and re-test date.
• Output: exception record with cause, effect, and the route taken.
• Owner: the control owner supplies the cause; assurance judges the effect; the risk owner approves acceptances. Governance decides whether the control stays as designed, risk prices the exposure, and compliance later shows the re-test that closed it.

3.8 Lay the tests across the period, not across the deadline#

A period is covered when every control has a test whose sample spans it. That is a calendar problem, solved before the period starts or not at all.

Three rules make it hold. Test quarterly controls quarterly, because four samples drawn in December cover December. Put a checkpoint at the halfway mark, so a failing control has time for remediation and a re-test inside the period. And set the calendar against the audit programme: clause 9.2.2 is titled Internal audit programme ²¹.

Results go into management review as decisions. Clause 9.3 is Management review, with 9.3.2 Management review inputs ²². The CSF Category for that loop is Oversight, GV.OV ²³.

• Input: the catalogue; the period start and end; the audit programme.
• Activity: place each control's tests across the period; set the checkpoint; reserve capacity for re-tests; publish before the period opens.
• Output: testing calendar, one row per control, with windows and a tester role.
• Owner: the assurance function; the officer approves the calendar.

3.9 Automate the part that is a query, and only that part#

A tool tests well where the control leaves a machine-readable record and the pass rule is unambiguous. Configuration drift, patch age, multi-factor coverage, orphaned accounts, backup job success: each is a query over a population the tool enumerates in full, which removes sampling from the argument.

A tool tests badly where the output is a judgement. Whether an access review was done with attention is not something a tool records. Reference control 8.16 expects networks, systems and applications to be monitored for anomalous behaviour, with monitoring records kept for defined retention periods ²⁴. That is a feed, not a conclusion. The matching CSF Category is Continuous Monitoring, DE.CM ²⁵; the plumbing is in GRC automation patterns. Two cautions. A tool testing its own coverage is measuring itself, and a continuous test still needs a population statement.

• Input: the test objective; the control's record format; the tool's coverage list.
• Activity: classify each test as automatable, partly automatable or judgement; write the pass rule; state the population reached.
• Output: automation split, one line per control, with the coverage limit named.
• Owner: the assurance function; the platform owner confirms coverage.

3.10 Write for the auditor who will re-perform the work#

An external auditor does not accept the conclusion, but tests whether it holds. Expect workpapers to be re-performed: the population re-extracted, the sample re-checked, an item traced end to end. Running the external audit covers that audit.

Four things fail under re-performance. A population that cannot be re-extracted. A sample that cannot be reproduced. Evidence held as a screenshot with no record identifier. And a conclusion stating the control passed without saying what it passed against.

The criteria set out the outcomes controls should ordinarily meet. That holds regardless of the specific controls management implemented ²⁶. Each point of focus is an important characteristic of the criterion it sits under. Using the criteria does not require assessing whether every one is addressed ²⁷. A workpaper answers the criterion; the points of focus are prompts, not a checklist.

• Input: the workpapers; the exception records; the testing calendar.
• Activity: re-perform a sample of the internal tests first; fix what does not reproduce; index workpapers to the criteria or clauses.
• Output: re-performance check, dated, listing what was reworked and why.
• Owner: the assurance function; the officer signs the index.

4. Deliverables#

Five artefacts, each from a step above. Retention and cadence are organisational choices.

Deliverable	Produced by	Format	Template
ITGC map	Step 3.1	one page per domain, versioned	template pending
Control test workpaper	Steps 3.3 to 3.6	workbook, one row per test	/templates/control-test-workpaper
Exception log	Step 3.7	table, cross-referenced to test IDs	same file, Exceptions sheet
Testing calendar	Step 3.8	one row per control, four windows	same file, Calendar sheet
Conclusion memo	Steps 3.6 and 3.10	one page, signed by role	template pending

The memo stays separate for one reason. The workpaper records what the tester did; the memo records what the owner concluded, and those signatures belong to different roles.

5. What the auditor will ask#

The order is consistent: population, sample, exception.

An audit that stays inside the workpapers is going well. One that moves to a folder of screenshots has its answer.

6. Failure modes and how they surface as findings#

Four patterns account for most re-performance failures.

The shared root cause is sequence: deciding what the test proved before deciding what it would test.

7. Mapping to standards (clause table, verified)#

Provenance. ISO/IEC 27001:2022 clause titles come from the contents listing ²⁸. ISO/IEC 27002:2022 numbers, titles and requirements come from a licensed copy, paraphrased ²⁹. Criteria identifiers are as printed, criterion text paraphrased ³⁰. CSF identifiers come from Appendix A ³¹.

Method step	ISO/IEC 27001:2022	ISO/IEC 27002:2022	Criteria	CSF	Evidence sampled
3.1 Access domain	8.1 Operational planning and control	8.2, 8.3, 8.5	CC6.1, CC6.2, CC6.3	PR.AA	Access review export with the reviewer named
3.1 Change domain	8.1 as above	8.32, 8.31, 8.19	CC8.1	PR.PS	Change record with authorisation, test and approval
3.1 Operations domain	9.1 Monitoring, measurement, analysis and evaluation	8.9, 8.15, 8.16, 8.8	CC7.1, CC7.2	DE.CM	Baseline comparison and monitoring records
3.1 Backup and recovery	8.1 as above	8.13 Information backup	A1.2, A1.3	PR.DS	Dated restore record naming the recovery point
3.2 Testable control statement	9.1 as above	5.36 Compliance with policies, rules and standards for information security	CC5.3	ID.IM	Objective written before evidence was requested
3.3 Population and completeness	7.5 documented information	8.9 Configuration management	CC4.1	ID.IM	Population record: query, boundaries, reconciliation
3.4 Sample and selection method	9.1 as above	5.36 as above	CC4.1	ID.IM	Sample record with method and drawn items
3.5 Procedure type and independence	9.2 planned internal audit programme	5.35 Independent review of information security	CC4.1	GV.OV	Tester role recorded apart from the owner
3.6 Workpaper	7.5.3 Control of documented information	5.36 as above	CC4.1	ID.IM	Signed workpaper with reviewer role
3.7 Exception to finding or acceptance	10.2 Nonconformity and corrective action	5.36 as above	CC4.2	ID.IM	Exception record with cause and re-test result
3.8 Testing calendar	9.2, 9.2.2 Internal audit programme	5.35 as above	CC4.1	GV.OV	Calendar with dated windows per control
3.9 Automation split	9.1 as above	8.16 Monitoring activities	CC7.2	DE.CM	Coverage list naming what the tool cannot reach
3.10 Re-performance check	9.3 Management review	5.35 as above	CC4.1	GV.OV	Dated list of workpapers reworked

One worked row. A quarterly access review is tested by inspecting four exports against a population of accounts from the directory. Reference control 8.3 limits access to information and associated assets to what the organisation's own access-control policy allows ³². The matching criterion is CC6.3, and the CSF Subcategory is PR.AA-05.

8. Checklist (interactive)#

Each item is observable. "Tested" is not; a dated workpaper with a named population is.

• Every control sits in one ITGC domain, or is an application control with its general controls named.
• Each test has a written objective naming the observable attribute and its record.
• Every population record states the source system, the query and the period boundaries, and carries a recorded completeness check.
• No sample is larger than its population, and every sample records its selection method.
• Departures from the house sample sizes are recorded with a reason, and no operating-effectiveness test relies on inquiry alone.
• No control is tested by the role that operates it, or the exception is recorded.
• Every workpaper names a tester role, a reviewer role and a date, and records evidence by record name.
• Every exception carries a cause, an effect, and a route: finding or acceptance.
• Re-test dates fall inside the period wherever remediation allows, and the calendar was published before the period opened.
• Automated tests state the population the tool actually reaches, and workpapers were re-performed internally before the external audit.
• Test results reached management review as decisions.

Related#

• Control ownership and the control catalogue — the catalogue and test plan this runs.
• Running the external audit — the audit that re-performs the work.
• Building an ISMS people actually use — internal audit under clause 9.2.
• GRC automation patterns — continuous control monitoring.
• SOC 2 type 1 in 90 days — where the period question arrives.
• Templates: Control test workpaper · Findings-to-closure tracker · Control catalogue.

References#

Primary sources only. ISO/IEC 27001:2022 clause titles come from the publisher's contents listing; ISO/IEC 27002:2022 control text from a licensed copy, paraphrased; criteria identifiers are as printed, with criterion text and points of focus paraphrased.

1. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. Contents and clause titles read at https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ²⁸
2. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. Controls 5.35, 5.36, 8.2 to 8.19, 8.31 and 8.32 read in a licensed copy; catalogue entry at https://www.iso.org/standard/75652.html ²⁹
3. AICPA (AICPA & CIMA), Assurance Services Executive Committee. 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus – 2022). TSP Section 100. Background and the CC4 to CC9 and A1 series read at https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022 ³⁰
4. ISO. Guidelines for auditing management systems. ISO 19011:2018. Clause 4 and the contents listing read in the publisher's document preview; catalogue entry at https://www.iso.org/standard/70017.html ⁷
5. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. Appendix A read at https://doi.org/10.6028/NIST.CSWP.29 ³¹

The four procedure types, the split between a test of design and a test of operating effectiveness, the house sample sizes and the term ITGC are GRCIDE's own working definitions and practice. They are attributed to no standard, and no attestation standard beyond the criteria document above was consulted.

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by AICPA, ISO, IEC, NIST or any other standards body.