How to Run a Quarterly Control Review: 4-Phase Process

A quarterly control review is a structured cycle for testing whether an organisation's internal controls are designed correctly and operating effectively. Each quarter, a GRC team records the results, agrees remediation actions, and reports findings to senior leadership. For most governance, risk, and compliance (GRC) teams, it's the main way a controls programme stays current between formal audits.

Where the cycle breaks down, the following year's audit findings show it. A control marked Effective got tested once, not four times. An evidence pack came together in the 48 hours before fieldwork. A control owner couldn't say whether their control had run last month.

Each review still happened on schedule and produced a document. None of that changed anything in the control environment.

A well-run quarterly control review moves through four phases in sequence. Each one has a gate: a defined output that must exist before the next phase begins. That's the mechanism separating a management discipline from a recurring task, and it is the first thing programmes drop when the quarter gets tight.

The six-week timeline assumes a control library of 100 to 300 controls that is already mapped. Building that library is a separate discipline: Chapter 4 of SureCloud's GRC Practitioner Guide covers designing a single internal control framework that maps obligations to practical controls across risk, compliance, audit, cyber and privacy. Programmes running 500 or more controls should extend testing to six weeks and compress reporting. Smaller libraries often close the full cycle in four.

Preparation usually decides how the rest of the quarter goes. When evidence requests go out late and control owners are unclear on what's expected, the GRC team spends the testing window chasing. It ends up evaluating whatever arrives in the final three days. Two weeks of preparation should produce a clean control library, a confirmed scope, and evidence requirements that owners understand.

The pre-review checklist

Run this at the start of every quarter. Anything still missing gets resolved before evidence requests go out.

1. Library hygiene: Retired controls are off the active list, and every control still on it is in use
2. Every control has a named owner with a current email address, and maps to at least one framework requirement
3. Testing frequency is set per control: quarterly, annual or continuous
4. Scope confirmation: This quarter's in-scope controls are agreed, whether that's the full library or a prioritised subset
5. Regulatory deadlines and audit windows falling inside the next 90 days are noted
6. Control changes since last quarter are documented: new, modified, retired
7. Evidence requirements: Evidence templates are defined per control type, with collection deadlines set two weeks before the review meeting
8. Owners have been briefed on what good evidence looks like for their specific control

That last item tends to pay back hardest. Most evidence problems in Phase 2 started as briefing problems in Phase 1. The owner submitted what they thought was wanted, and nobody found out until the reviewer opened the file six weeks later.

Translating a policy requirement into a specific, datable evidence request is its own skill. The companion guide in this hub on turning policy requirements into evidence requests works through it control type by control type.

Full library or prioritised subset

One rule holds across all three. Any control that changed since the last review, or that feeds a regulatory obligation with a deadline inside 90 days, is in scope every quarter.

One control, three frameworks

Most control libraries carry heavy overlap. A single access review can satisfy an ISO/IEC 27001 Annex A control, a SOC 2 common criterion and a DORA ICT requirement at once. The temptation is to test it three times because three reports want it. Test it once, to the strictest evidence standard among the frameworks it serves, then map that single result to each.

What changes per framework is the reporting cadence and the retention period. Where two frameworks want different evidence from one control, the control is doing two jobs and should be split in the library.

Testing is often where quality varies most, because people mean different things by it. A control counts as tested when a reviewer has evaluated its evidence against two things: the control's design, and its operating effectiveness. Those are separate activities, and they need separate people: the owner who supplies the evidence, and the reviewer who judges it.

Design effectiveness and operating effectiveness

The clearest published definitions come from financial audit practice, and they're worth borrowing. AS 2201, the Public Company Accounting Oversight Board standard governing audits of internal control over financial reporting, separates the two cleanly: testing design effectiveness asks whether controls, operated as prescribed by people holding the necessary authority and competence, satisfy the control objectives, while testing operating effectiveness asks "whether the control is operating as designed and whether the person performing the control possesses the necessary authority and competence to perform the control effectively." The subject matter differs from an access review or an encryption standard, and the two questions carry across unchanged.

The distinction earns its place because the two fail differently. A control can operate flawlessly every month and still address the wrong risk, and no amount of quarterly operating-effectiveness testing will surface that. Design failures usually appear at implementation, then resurface when the risk landscape shifts or a new regulatory requirement gets mapped onto an existing control.

Testing methods

Method choice generally follows risk. AS 2201 puts it this way: "As the risk associated with the control being tested increases, the evidence that the auditor should obtain also increases." Inspection is usually enough for a low-risk policy control. Re-performance is generally worth the effort once a control is high-risk and automated.

What actually drives sample size

For controls that operate continuously, testing every instance is impractical, so most programmes sample, and the common mistake is treating sample size as a simple function of population. AS 2315, the same body's standard on audit sampling, sizes a test-of-controls sample on three factors: "the tolerable rate of deviation from the controls being tested, the likely rate of deviations, and the allowable risk of assessing control risk too low." Population size shapes which sizing table applies at the small end, and stops mattering much once a population is large.

That produces smaller numbers than most teams expect. Writing in Linford & Company's guidance on audit sampling in SOC examinations, Nicole Hemmer works a security training example across 389 employees: an initial sample of 25, expanded to 40 on finding one deviation, and to 60 on a second. Document whichever methodology you use. Auditors will ask, and "we picked twenty" is a hard answer to defend a year later.

The evidence quality problem

The single biggest cause of inconclusive testing results is evidence that fails to cover the review period, and the audit standards are precise about why. Evidence drawn from observation, AS 1105 notes, is "limited to the point in time at which the observation takes place." An access review screenshot captured on testing day tells you access was reviewed on testing day. It says nothing about the other 89.

The same standard separates evidence quality into sufficiency, "the measure of the quantity of audit evidence," and appropriateness, "the measure of the quality of audit evidence." Relevance is defined by "its relationship to the assertion or to the objective of the control being tested." Reliability rises when evidence comes from a system that's independent of the person who owns the control.

Three questions apply that to any evidence pack.

1. Does it cover the period?
   Evidence should span the full quarter, from the first working day to the last

2. Does it show the control operated?
   A policy document shows the control exists. A log or an approval record shows it ran
   
   
3. Is it independently verifiable?
   System-generated output carries more weight than an owner's own attestation

An evidence pack that answers all three survives an external auditor reading it cold twelve months later. Where one of the three is missing, the gap can usually still be closed inside the same quarter, provided the review catches it before fieldwork does.

The review meeting turns draft statuses into decisions. It's the most commonly misrun hour in the cycle: a meeting that ratifies whatever the GRC team already concluded is a sign-off meeting with a review's name on the agenda. Phase 3 exists to apply judgement to draft results, surface disagreements, agree remediation, and produce a decision log the organisation can act on.

Who should be in the room

1. Compliance Lead: chairs, confirms or adjusts draft statuses, and signs the decision log
2. GRC Operations Manager: presents draft results and flags borderline cases for discussion
3. Risk Manager: updates the risk register with control failures identified, attending as a participant holding a task
4. Control owners for disputed controls: join for the relevant agenda item only

A well-prepared Phase 2 means most controls are confirmed in seconds, which usually leaves the hour free for the handful that need discussion. When evidence collection stalls, the cause is usually an ownership gap that should have been closed in Phase 1, and assigning control ownership across teams is handled as its own guide in this hub.

The four statuses and their criteria

The borderline case is the recurring argument: should a control with minor gaps be rated Partially Effective or Effective? One question settles it. Would an external auditor, reading this evidence pack cold, conclude the control operated as designed throughout the period? If the answer is uncertain, the rating is Partially Effective.

Exception requests and systemic patterns

Some owners will push back on a Partially Effective or Ineffective rating, or ask for a known gap to be formally accepted. Those requests are legitimate in defined circumstances: a compensating control covers the exposure, remediation cost is disproportionate to the risk, or a regulatory deadline makes immediate remediation impractical. They belong in a structured exception process with intake, risk assessment, tiered approval and an expiry date, handled outside the review meeting. The companion guide on handling an exception request sets that process out end to end.

Before closing Phase 3, read the full set of results for patterns that individual control reviews hide.

1. Are the same control types rated Partially Effective across different owners?
2. Are Ineffective controls concentrated in one business unit or framework domain?
3. Has any control been Partially Effective or Ineffective for two or more consecutive quarters?

A systemic pattern is usually a different problem from an individual control failure. It points at process or design, and the response belongs at programme level with the Compliance Lead.

Reporting is where the review becomes visible to the people who act on it: senior leadership, the board, external auditors, regulators. Two outputs, two formats.

The operational report

This is the working document for the GRC team and control owners: detailed, structured, and machine-readable where the tooling allows. It carries:

1. Total controls in scope, broken down by status
2. Quarter-on-quarter trend in the proportion rated Effective
3. Open remediation actions with owners, deadlines and priority
4. Escalations made to the risk register, with the associated risk IDs
5. Controls due for re-test before the next cycle

Raw evidence packs, testing workpapers and meeting notes stay in the evidence repository and get linked from the report.

The executive summary

Senior stakeholders have little use for the fact that 14 controls were Partially Effective. They need to know whether the control environment is improving, where the material risks sit, and what decisions are required of them. Three questions structure it: where are we, what are the material risks, and what do we need from you.

The first is one paragraph: this quarter's control effectiveness rate against last quarter's, and the direction of travel. The second is bullets, covering any Ineffective control mapped to a regulatory obligation with the deadline attached. The third is explicit asks: budget decisions, escalation sign-offs, resource commitments.

The test is simple. A board member who reads it in three minutes should be able to say whether the control environment is getting better or worse and what needs fixing. Everything that fails to serve that answer belongs in the operational report.

Closing the quarter

1. Testing workpapers filed in the evidence repository with the correct quarter label
2. Remediation actions logged in the risk or action management system with named owners
3. Control library updated with final statuses
4. Next quarter's calendar confirmed: start date, evidence deadline, review meeting date
5. Lessons learned documented: what ran late, what evidence was missing, what would make next quarter faster

That last one gets skipped most and compounds most. For EU financial entities it is also a legal requirement. DORA, the EU's Digital Operational Resilience Act, has applied since 17 January 2025, and Article 6(5) requires that the ICT risk management framework "shall be documented and reviewed at least once a year" and "shall be continuously improved on the basis of lessons derived from implementation and monitoring." A quarterly cycle that records what it learned is how that second obligation gets evidenced.

One reference to run at the start of each quarter. Every task carries a phase, an owner, and the gate it feeds.

Even a well-designed cycle fails in fairly predictable ways. Four patterns account for a lot of it.

Evidence collection takes up the testing window

The GRC team spends Weeks 2 to 4 chasing owners and evaluates whatever arrives in the final three days. Behind it sits some combination of unclear requests, unenforced deadlines, and owners who have never been told what good looks like. Standardised evidence templates per control type solve the first two. A visible tracking log showing which owners have yet to respond solves the third, because it creates accountability without anyone needing to chase individually.

Controls pass internally and fail externally

This one can cost credibility. Controls sit at Effective quarter after quarter, then an external audit produces findings against them. Usually the testing has drifted into evaluating evidence quality when it should be evaluating control effectiveness, and a well-formatted evidence pack is a different object from a well-operating control. Define, per control, what effective looks like operationally, then re-perform a sample each quarter, since re-performance tends to surface what inspection misses.

The timing is what costs you. A finding raised in fieldwork gets remediated on the auditor's schedule and appears in the report. The same gap, caught in Q1, can usually be closed on your own schedule.

Remediation actions get agreed and never completed

An action logged with no owner, no escalation path and no consequence for a missed deadline is a note. The signal that a programme has accumulated a page of notes is the same controls appearing as Partially Effective or Ineffective quarter after quarter, with fresh remediation actions each time.

Move them into a system that sends reminders and escalates overdue items. Review open actions mid-quarter. Send anything still overdue at the start of a new cycle to the Compliance Lead before that cycle begins.

The review is disconnected from the risk register

Risk owners hearing about control gaps for the first time at risk committee is the tell. It happens when the review process and the risk process run on different tools with no formal handoff, so control failures get documented in the review record and stop there. The Phase 3 decision log should feed the register directly: every Ineffective control generates or updates a risk entry, automatically or through a defined manual process with a named owner and a five-day SLA. SureCloud's Complete Guide to Risk Registers covers how to structure the register so control escalations land as linked entries with an owner, a score and a treatment plan.

A well-run quarterly review is a large improvement on the status quo. It also carries a structural limit: it tells you about the past. A control can fail on day one of the quarter and operate correctly for the remaining 89 days, and the quarterly review will rate it Effective. The failure goes undetected until something else surfaces it.

That's an argument for matching cadence to control type. Policy reviews, access certifications, vendor assessments and management attestations all suit a quarterly rhythm, because they involve human judgement and the underlying state changes slowly. Technical controls that run continuously, such as log monitoring, vulnerability scanning, encryption status and backup integrity, drift between snapshots.

ISACA has looked at this directly. Writing in the ISACA Journal, Michael Powers notes that "sampling has limitations, including the potential for flawed population selection, inadequate coverage of the true population" and that control testing performed on a set frequency "can be inefficient."

His case study at a US regional banking institution moved technology control testing from a sample of 25 applications to 100% coverage of nearly 300. The effort dropped from 0.38 of a full-time equivalent to 0.11, with on-demand and weekly continuous monitoring replacing semi-annual manual tests.

What continuous monitoring changes

Continuous controls monitoring (CCM) tests programmatically monitorable controls on an ongoing basis and alerts when configuration drifts. That's a different thing from capturing a screenshot once a quarter. NIST's guidance on continuous monitoring describes the purpose as providing "visibility into organizational assets, awareness of threats and vulnerabilities, and visibility into the effectiveness of deployed security controls." Applied to a quarterly cycle, it changes three things.

Quarterly reviews and continuous monitoring run on different cadences for different control types, and they do different jobs in the assurance architecture. The quarterly review is the management cycle: human judgement applied to results, status decisions made, remediation agreed, governance record produced. Continuous monitoring is the operational layer underneath, generating the testing record the review consumes and surfacing exceptions between meetings so they stop waiting 90 days to be found.

Put together, the quarterly cycle opens with a complete testing record and the review meeting spends its hour on decisions. SureCloud's Continuous Controls Monitoring tests controls continuously across cloud, security, identity and enterprise tools, and because the control library and the risk register sit in the same platform, an Ineffective control updates its risk entry without the manual handoff that otherwise leaves control failures sitting in the review record. Gracie AI Agents with Personas and Skills then analyse control performance across the period, identifying trends, preparing audit reports, and showing the board how control drift connects to other business risks. SureCloud puts the effect at a 75% reduction in audit preparation time.

None of this is complicated to describe. The gap between a team that runs it well and one that struggles is rarely knowledge: it's usually unclear ownership, missing gates, and no mechanism to turn findings into management decisions.

Run it once with the four gates in place. Document what ran late and what evidence was missing. Adjust the timeline to your library size and rebuild the evidence templates around what owners actually submitted. By the third quarter it should run faster and produce better results than whatever preceded it.

Three companion guides in this hub handle the adjacent disciplines: preparing for a customer security questionnaire, handling an exception request, and assigning control ownership across teams. Each removes a specific source of friction from the cycle above. The clearest sign it is working is a quarter where the team spends more of Weeks 2 to 4 evaluating evidence than asking for it.