A recurring control-testing calendar turns compliance from a last-minute audit project into an operating routine. This guide shows SaaS teams what to test monthly, quarterly, and annually, which evidence to retain, how to assign owners, and when changes should trigger an earlier review.
Overview
Security controls are not proven by policies alone. A policy may describe how access, backups, vulnerability management, or incident response should work, but testing demonstrates that the process operates as intended. For a SaaS company preparing for SOC 2, ISO 27001, customer security reviews, or broader cybersecurity compliance, the objective is to create a repeatable record of control performance.
A useful compliance calendar connects four elements: the control being tested, the frequency, the responsible owner, and the evidence that demonstrates completion. It should also record exceptions rather than hiding them. An incomplete test with a documented explanation and remediation plan is more useful than a calendar marked complete without supporting evidence.
Use the schedule below as a baseline rather than a universal rule. Your audit period, contractual commitments, risk assessment, system changes, and chosen framework may require more frequent testing. Map each activity to the applicable control or requirement in your internal control matrix, then confirm the final schedule with the people responsible for security, privacy, legal, and operational risk.
What to track
Build one control-testing register instead of scattering evidence across email, chat, and personal folders. Each row should contain:
- Control name and objective: State what risk the control addresses, such as unauthorized access or loss of customer data.
- Framework mapping: Link the control to relevant SOC 2 criteria, ISO 27001 controls, customer commitments, internal policies, or legal obligations where applicable.
- Test procedure: Explain the steps a reviewer will perform, including the population or sample, system used, and pass criteria.
- Frequency and owner: Assign a named role or team, not merely “IT.” Separate the person performing the control from the reviewer when practical.
- Evidence location: Record the controlled repository, file name, query, ticket, report, or system link. Evidence should show the relevant date and scope.
- Result and exception: Use clear statuses such as effective, partially effective, failed, not applicable, or not tested. Add the reason and remediation reference.
- Review date: Include the next scheduled test and any earlier due date created by a change, incident, or exception.
Monthly control tests
Monthly checks are most valuable for controls that change frequently or would create material exposure if they failed for several weeks. Consider testing:
- Privileged and administrative access, including new accounts, terminated users, role changes, and unusual permissions.
- Backup completion, failed jobs, retention settings, and a sample restoration or restoration validation where feasible.
- Vulnerability and patch-management queues, including overdue critical findings and documented risk acceptances.
- Security alerts, open incidents, and unresolved recommendations from prior investigations.
- Endpoint, cloud, and production monitoring coverage, including disabled agents or logging gaps.
- New vendors, subprocessors, and high-risk changes that entered the environment during the month.
Typical monthly evidence includes access-review exports, backup reports, vulnerability scans, remediation tickets, incident logs, monitoring dashboards, and approval records. Avoid retaining only a screenshot with no date or scope; pair system output with a short reviewer note explaining what was checked.
Quarterly control tests
Quarterly reviews are suited to controls that need management attention or a broader sample. Review user access across critical applications, test a sample of joiner-mover-leaver tickets, reassess high-risk vendors, and verify that security and privacy training records remain current. Reconcile the asset inventory with cloud accounts, repositories, production services, and data stores.
Quarterly testing is also a good point to review risk-register entries, outstanding exceptions, security questionnaires, and customer commitments. If privacy operations are in scope, check whether processing activities, data flows, retention rules, and consent or tracking configurations have changed. Supporting work may include a vendor risk assessment, an updated data-processing review, or evidence from the team’s incident response process.
Annual control tests
Annual activities should test the resilience and governance of the program, not merely repeat monthly checks. Schedule a formal risk assessment, policy review, business continuity and disaster recovery exercise, incident-response tabletop, and management review of control performance. Review whether the control design still matches the product architecture, customer commitments, data use, and threat environment.
Annual evidence may include approved policies, risk-assessment outputs, continuity test results, tabletop minutes, recovery objectives, training attestations, internal audit findings, and documented management decisions. Use the SOC 2 readiness planning guide or an internal ISO 27001 audit checklist to identify gaps between control descriptions and the evidence your team can actually produce.
Cadence and checkpoints
A practical calendar starts with a short monthly closeout and builds toward quarterly and annual reviews.
- At month-end: Control owners complete assigned tests, attach dated evidence, and create remediation tickets for failures. A security lead reviews overdue items and confirms that exceptions have owners and due dates.
- At quarter-end: The compliance or security program owner checks trends, samples completed tests, reviews high-risk vendors and access, and escalates repeated failures. Management should see material risks, not an undigested list of every ticket.
- At year-end or before an audit: Reconcile the control register to the audit scope, confirm the testing period, check for evidence gaps, and perform a readiness review. Do not wait until the auditor requests a control if its owner, test method, or evidence location is unclear.
Use a consistent evidence-log format: control ID, test period, tester, test steps, sample or population, result, evidence link, exception ID, reviewer, and completion date. A reusable evidence library also makes customer questionnaires easier to answer; see the SaaS compliance evidence library guide for a related workflow.
How to interpret changes
Control testing is not just a completion metric. Look for changes that indicate increasing risk or weakening process discipline:
- A growing number of overdue vulnerabilities, access reviews, or remediation tickets.
- Repeated exceptions with the same root cause or an expired risk acceptance.
- More manual workarounds, unexplained evidence gaps, or tests completed after the required period.
- Changes in architecture, hosting, data flows, subprocessors, or product functionality that are absent from the control register.
- Backup jobs that succeed technically but have not been restored or validated recently.
- Incidents, near misses, or customer findings that do not lead to a control update or new test.
Classify each exception by impact, affected systems or data, temporary safeguards, owner, target date, and approval. A failed test does not automatically mean the entire program is ineffective, but an unexplained or recurring failure deserves escalation. Trend results by control family so leadership can distinguish an isolated defect from a systemic issue.
When to revisit
Review this calendar at least quarterly and perform a fuller refresh annually. Revisit it sooner after a security incident, material product or infrastructure change, new customer requirement, new subprocessors, major access-model change, acquisition, audit finding, or change to the scope of a SOC 2 or ISO 27001 assessment.
At each review, ask five practical questions:
- Does every material risk have a control, owner, test method, and evidence source?
- Is the frequency appropriate for how quickly the risk can change?
- Can an independent reviewer understand the test without asking the owner to recreate it?
- Are exceptions tracked through completion, including compensating controls?
- Do framework mappings and customer commitments still match the current product and operating model?
To put the calendar into operation, start with the next 30 days: assign owners, define pass criteria, test access and backups, capture vulnerability and incident evidence, and create a single exception log. Then schedule the next quarterly review and annual exercise on the same calendar. This small routine creates audit-ready compliance over time and gives the team an earlier warning when security controls stop matching the business.
