Learn · SOC 2 Operations

Continuous Monitoring and
Year-Round Evidence

A SOC 2 Type 2 tests whether controls operated throughout a stated period. That one word — throughout — is why programmes fail in the last four weeks: evidence for month three cannot be created in month twelve, and the timestamps say so.

The reframing that matters: stop treating evidence as something you collect and start treating it as something your systems emit. A control that only exists when someone remembers to screenshot it is not a control — it is a chore with a deadline you will eventually miss.

Talk to a Compliance Advisor How to Read a SOC 2 Report

12 mothe unit of testing in a Type 2 — the period, not a date

CC4.1the criterion on ongoing and/or separate evaluations

250+SOC 2 engagements supported by TCSA

Plain-English explainer · TSC 2017 (rev. points of focus 2022) · AT-C 205 examination · Last reviewed August 2026

A SOC 2 Type 2 reports on whether controls operated effectively throughout a stated period, not on whether they worked the day the auditor looked. Because the period is the unit of testing, evidence for the months you did not manage well cannot be reconstructed at the end — and the four weeks before fieldwork are where under-instrumented programmes discover it. The service auditor does not sample your intentions. For each control they define a population — every instance it should have operated during the period — select from it, and inspect what the system recorded at the time. A backdated approval, a catch-up review, or a screenshot taken last Tuesday for a control due in March all fail the same way: they are artefacts about the period rather than artefacts from it. Year-round monitoring is not a maturity badge; it is the only thing that produces a testable population.

Key Takeaways

A Type 2 opinion addresses operating effectiveness throughout a stated period, so the population an auditor samples is the whole period — evidence for a skipped quarter cannot be manufactured later, and the attempt shows in the timestamps.
The same four controls break first almost everywhere: access reviews (CC6.3), removal of credentials on termination (CC6.2), change approval before deployment (CC8.1) and vulnerability remediation inside the SLA you wrote (under CC7.1) — calendar failures, not technology failures.
Evidence should live in the system that already performs the work — identity provider, git host, ticketing, HR — because those timestamp and attribute automatically, and a folder of screenshots does neither.
Default log retention is the quiet killer: Okta System Log at 90 days, Entra ID at 7 or 30, CloudTrail Event History at 90, GitHub Actions logs at 90. A control that operated without a surviving record tests identically to one that never operated.
Compliance automation platforms genuinely collect, monitor and alert. They do not attest, do not define your population, and cannot see an account, tenant or laptop that was never connected — which renders as compliant rather than as failing.
Monitoring for compliance and monitoring for security answer different questions — did the control operate, versus did something bad happen. CC4.1 asks the first, CC7.2 the second.

The structural problem

Why evidence cannot be retrofitted

A Type 1 asks whether controls were suitably designed and implemented as at a single date. A Type 2 asks whether they operated across a span of time, which turns a description into a census.

The population is the period, not the sample

Before anything is selected, the auditor needs the complete list of instances the control should have operated — every termination, every deployment, every review cycle — from a source system, and its completeness is tested in its own right. Teams prepare for the sample and are ambushed by the population request that precedes it.

Evidence must be reliable, not merely present

Under the attestation standards governing examinations (AT-C 205, with common concepts in AT-C 105), the practitioner evaluates whether information used as evidence is relevant and reliable, including its accuracy and completeness. Auditors call the listings and reports you generate IPE — information produced by the entity — and testing IPE is a step in its own right, which is why a hand-assembled export is weaker than one the auditor watches you generate.

Timestamps outlive good intentions

A retrospective approval carries the date it was created, not the date it should have existed. A catch-up review shows a nine-month span and a completion date after period end. Reconstruction leaves fingerprints, and they end up in the tests-of-controls column of Section 4.

The criteria point the same way. CC4.1 asks the organisation to select, develop and perform ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning — either kind satisfies the criterion, and neither is mandatory on its own. Its points of focus, which are considerations rather than requirements, go further: they ask management to include a balance of ongoing and separate evaluations and to build the ongoing ones into business processes rather than bolting them on beside. The criteria never use the vendor phrase “continuous monitoring” — but the idea is unmistakably CC4.1, and the difference between meeting it and not is usually a calendar.

Failure order

The controls that break first

The failure order is remarkably consistent, and it is never the sophisticated controls. It is the recurring ones with a human owner, a soft deadline and nothing enforcing it.

Control	How it actually fails	What the auditor sees
Quarterly user access reviewCC6.3	A quarter slips while the owner is on leave, then one catch-up review runs near period end covering everything.	Three campaign records against a population of four, one dated after period end and spanning nine months.
Offboarding within one business dayCC6.2	The identity provider is cleared on day one; database roles, VPN and directly-administered SaaS linger. Contractors never enter HR.	A leaver population that will not reconcile to deprovisioning events, and samples closed eleven and thirty-four days late.
Change approval before deploymentCC8.1	The approval exists but the merge preceded it. Urgent fixes ship with no ticket and get written up later.	Approval timestamps later than deployment timestamps, and deployments with no corresponding change record at all.
Vulnerability remediation within SLACC7.1 (detection)	Criticals get fixed. Highs age past the window, re-triaged verbally, the clock informally reset at each new scan. The thirty-day SLA is your own wording in the control description, not a number the criterion sets — which is exactly why the auditor tests you against it.	One finding across four consecutive scan exports with no ticket, no documented risk acceptance and no remediation date.
Alert and anomaly reviewCC7.2 / CC7.3	Detection fires correctly. Nobody records the disposition of alerts investigated and closed as benign.	Capable tooling, and no evidence a human evaluated whether any anomaly was a security event.
Annual restoration testA1.2 / A1.3	The backup job succeeds nightly for a year and nobody restores from it, because a restore needs a scheduled window.	A backup-success dashboard offered against a control that promised a tested recovery — a different assertion.
Vendor security reviewCC9.2	Procurement keeps adding vendors. Reviews happen for the obvious three at onboarding, then nothing triggers them again.	A vendor population from accounts payable that is materially longer than the list actually reviewed.

A note on the mappings, because firms differ: offboarding is written here to CC6.2 because that criterion carries the explicit language about removing user system credentials when access is no longer authorised, while the periodic review of whether access remains appropriate sits in CC6.3. Both readings are defensible and most controls map to more than one criterion — what matters is that your matrix is consistent with itself.

Notice what is absent from the middle column: nobody was negligent and nothing was technically hard. Each failure is a recurring obligation whose only enforcement was somebody’s memory. That is the design defect, and fixing it costs nothing.

Where evidence should live

The system of record, not a folder

The strongest evidence is a by-product of doing the work, produced by a system the control operator cannot quietly edit. The weakest is a document assembled to be evidence. The middle column names the specific setting, not the category — because the setting is what you have to go and change.

Control	System of record and the setting that matters	What the auditor pulls	What breaks it
Change authorisation	GitHub branch protection, or GitLab merge-request approval rules: required approving reviews of at least one, admin enforcement on, force-push disabled on the protected branch.	The pull-request or merge-request record — approving reviewer, review timestamp, merge timestamp, and the CI run that gated it.	Admin bypass left enabled, force-push permitted, or a reviewer approving their own change.
Access provisioning	Ticketing for the approval — a Jira workflow validator requiring a populated approver field before the Deploy or Grant transition — plus the Okta System Log or Entra ID audit log for the grant itself.	The ticket showing requester, approver and role, joined to the identity-provider event that created the entitlement.	Access granted directly in a console with no ticket, or group membership changed under a shared administrative login.
Offboarding	The HR system (BambooHR, Workday, Zoho People) defines the population; Okta or Entra ID records the deactivation and session revocation.	The full termination list — employees and contractors — joined to deprovisioning events, with elapsed time per person.	Contractors and service accounts absent from HR; a leavers spreadsheet kept by the control owner as the only complete list.
User access review	A scheduled certification campaign — Okta Identity Governance access certifications, Microsoft Entra ID Access Reviews, or the equivalent in your governance tool.	Campaign export: every entitlement, its reviewer, the decision, the decision date, and the revocations that followed with their own timestamps.	A workbook emailed round with no revocation trail — a review that changed nothing shows nothing.
Infrastructure configuration	AWS Config rules for current state and CloudTrail for the change history behind it; Azure Policy with the Activity Log, or Organization Policy with Cloud Audit Logs, do the same job.	The rule evaluation showing compliant resources at a point in time, plus the change events for that setting across the period.	Current state offered on its own. A screenshot of today evidences today, not the eleven months before it.
Vulnerability management	Scanner plus ticketing, linked by finding identifier so the SLA clock has a start and a stop.	Unfiltered scan population including closed findings, each finding’s first-seen date, the linked ticket, the closure date.	An export filtered to open findings, or findings closed in the scanner with no remediation record behind them.
Incident response	A dedicated incident tool or on-call platform — PagerDuty, Opsgenie, incident.io — rather than a chat channel.	Declaration time, severity, responders, the timeline, resolution and the post-incident review.	Incidents run in chat and never written up, leaving no population to sample from.
Awareness training	The learning platform records completion; the HR roster defines the population.	Completion across the full roster, including joiners and their individual deadlines.	A tile reading ninety-two per cent, with no roster and no view of the missing eight.
Backup restoration test	Runbook, ticket and infrastructure logs — the restore, not the backup job.	Restore ticket with start and finish timestamps, the validation performed, and the sign-off.	A screenshot of successful nightly jobs, which evidences backup rather than recovery.
Subservice organisation monitoring	Your vendor register, plus each subservice organisation’s current SOC 2 report and the CUECs it assigns to you.	Evidence you obtained the current report, reviewed it with a named reviewer and a date, noted its exceptions, and operated each CUEC assigned to you.	A report downloaded and filed. Obtaining is not reviewing, and the CUECs are controls you have to run yourself.

The generalisable pattern is enforcement at the point of action. Branch protection that refuses a merge without an approving review beats a policy requiring approval, because the control cannot be skipped and the record cannot be omitted. A Jira workflow validator that will not transition an issue to deploy without a populated approver field beats a change board that meets when it can. Every setting in the middle column shares that property: it makes the compliant path the only path.

Control design

Controls that generate their own evidence

Run every control through five questions before it enters the matrix. One that fails any of them will cost you evidence work every month for a year — and the fourth column is what it costs.

Question	A control that passes	A control that fails	What it costs you
01Does normal operation leave a timestamped record?	The merge cannot land without an approving review, so the record is a by-product of the act.	A monthly check somebody screenshots when they remember to.	Every instance becomes a manual retrieval, and the ones nobody remembered become exceptions.
02Is the record attributable to a person?	A named reviewer on the pull request; a named approver field on the ticket.	Actions taken through a shared administrative login or a bot token nobody owns.	Approval independence cannot be tested, so the control fails on design however well it ran.
03Can you produce the complete population from a system?	A termination list exported from the HR system with the filter, date range and run time visible.	A leavers tab the IT manager maintains alongside the real work.	Completeness cannot be demonstrated, so the sample supports no conclusion and the rework lands mid-fieldwork.
04Is the record outside the operator’s control?	An immutable identity-provider audit event; protected-branch history the author cannot rewrite.	A shared-drive folder the control owner can edit, replace or quietly re-date.	The evidence is downgraded, and the auditor extends testing or seeks corroboration elsewhere.
05Does the stated frequency match what you can sustain?	“Within fifteen business days of each quarter end” — four instances and a written tolerance.	“Daily” written for a task the team actually performs when the queue looks busy.	A population of roughly 250 business days, and a duty to explain every gap inside it.

The same control, written twice

Weak

“Management periodically reviews user access to production systems and removes inappropriate access.”

Testable

“Within fifteen business days of each quarter end, system owners review all user entitlements to in-scope production systems through an access-review campaign in the identity provider. Each entitlement is approved or revoked by a reviewer other than the entitlement holder, and revocations are completed within five business days.”

The second version states the population, the tolerance, the independence requirement, the completion criterion and the system holding the record. Periodically does none of that — it invites the auditor to decide what you meant.

Cadence

A monitoring rhythm by control frequency

Frequency drives the population size, the sample size and the kind of trigger that keeps a control alive. The AICPA prescribes no sample sizes for SOC 2 — the ranges below are market convention from audit sampling practice, and the service auditor sets the real numbers from population size, frequency, expected deviations and assessed risk. The full mechanics — how a deviation rate is computed and when a deviation becomes an exception — are in SOC 2 sampling and sample sizes.

Frequency	Example controls	12-month population	Typical sample	Trigger mechanism
Continuous / automated	Branch protection, MFA enforcement, encryption and logging configuration	Every change, host or repository in scope	Configuration inspected once, plus corroboration it held across the period	Platform or CI check on a schedule; the change log for the setting is the corroboration
Daily	Alert triage, backup monitoring, failed-login review	~250 business days	20–40	Scheduled ticket auto-created each morning, closed with the disposition written in
Weekly	Vulnerability triage, patch review, ticket ageing	52	5–9	Recurring calendar invite with a named deputy, producing one written outcome
Monthly	Privileged-group recertification, joiner/leaver reconciliation, SLA ageing	12	2–4	Ticket auto-created on the first of the month, assigned to a person not an inbox
Quarterly	Full access review, risk register review, management review of control performance	4	2	Certification campaign scheduled in the identity-provider console, not raised by hand
Annual	Policy approval, risk assessment, penetration test, restoration test, training	1	1	Pinned to a named month early in the period, with the window booked in advance
Event-driven	Onboarding, offboarding, incidents, emergency changes, vendor onboarding	Unknown until you reconcile against the source system	Often all of them below roughly 25 items	Monthly reconciliation against the system that defines the population

Twenty-five is the usual starting point for a daily control, rising towards forty as the expected deviation rate rises. Populations below roughly twenty-five items are normally tested in full, because sampling stops saving anybody effort. And the numbers scale to the observation period rather than the calendar: in a three-month Type 2, a monthly control has a population of three.

The quarterly operating calendar

One rhythm, repeated four times

Bound below to an observation period running 1 October to 30 September — the same period as the worked example further down — so the months are real rather than abstract. Each quarter closes, with evidence reconciled and archived, before the next opens. Programmes that leave quarters open find in month twelve that they have one enormous quarter and no records.

Month 1 — October, January, April, July

Open the cycle

The access-review campaign opens between the 1st and the 10th and closes by the 31st, with revocations tracked to completion.
Privileged-group recertification for production, cloud root and database roles.
Last quarter’s evidence reconciled, archived and closed — nothing stays open across two quarters.

Month 2 — November, February, May, August

Test yourself

Risk register reviewed; risk acceptances re-confirmed or withdrawn, never rolled forward silently.
Test two controls the way the auditor will: define the population, sample it, inspect the artefact.
Subservice SOC 2 reports reviewed when reissued, and the CUECs assigned to you confirmed as operating.
Confirm retention windows still exceed the remaining period for logs, tickets and scan history.

Month 3 — December, March, June, September

Evaluate and minute it

Management review of control performance, minuted with attendees and decisions before the month ends — the separate evaluation contemplated by CC4.1.
Reconciliations: HR leavers against deprovisioning, deployments against change records, vendor spend against reviews.
Open exceptions dispositioned; next quarter’s calendar confirmed with named owners and deputies.

Every month, regardless

Joiner and leaver reconciliation between HR and the identity provider. An SLA ageing report that includes findings approaching the limit, not only those past it. Training completion for the month’s new starters. A scanner export covering closed findings as well as open ones, kept where your scanner’s own history cannot reach it.

The final thirty days

Freeze, do not create. Run the full-period reconciliations, assemble the evidence pack before the request arrives, and confirm every export can be regenerated on demand. If something has to be built now, the finding already exists.

Retention

The defaults that delete your evidence

Almost every source below ships with a retention window shorter than a twelve-month observation period. The control operates all year, the record quietly expires, and the test cannot be performed. This is the single cheapest thing to fix and the one most often found too late — the settings take an afternoon, and only before the period opens.

Evidence source	Documented default	What it costs you at 12 months	The setting to change
Okta System Log	90 days	Grant, revocation and sign-in events for months one to nine are gone before fieldwork opens, taking provisioning and offboarding evidence with them.	Turn on Log Streaming to a SIEM or an S3 bucket, or export the System Log monthly and archive the exports with their parameters visible.
Microsoft Entra ID sign-in and audit logs	7 days on the free tier; 30 days on P1/P2	Almost nothing survives to fieldwork. Even a quarterly access review can lose its revocation evidence before the next quarter opens.	Route diagnostic settings to a Log Analytics workspace or storage account with retention longer than the observation period plus fieldwork.
Google Workspace admin and user log events	6 months for most report data	The first half of a twelve-month period is unavailable, so admin changes and account events for months one to six cannot be re-pulled.	Schedule exports through the Reports API, or forward log events to BigQuery and keep them for the period plus a margin.
AWS CloudTrail Event History (console)	90 days of management events	Configuration-change history disappears. You can show current state but not who changed a security group in month two, or whether it was changed at all.	Create a trail delivering management events to S3 — one copy is free from CloudTrail, S3 storage is billed — with a lifecycle policy longer than the period.
GitHub audit log	180 days for enterprise audit events; 7 days for Git events	Branch-protection and admin changes from the first half of the period are unavailable, and raw Git push history is effectively not evidence at all.	Enable audit log streaming to your log store, and lean on the pull-request record — which persists with the repository — for change evidence.
GitHub Actions run logs and artifacts	90 days	The CI run that gated a merge in month three is gone, so a change control whose wording relies on “CI passed” loses its artefact.	Raise the retention period in repository or organisation settings — private and internal repositories allow considerably more than the default — or archive the run summary with the release record.
Jira projects and issues	Issue history persists with the issue; a trashed project holds its issues for 60 days, then they are permanently deleted	Not decay but deletion. A tidy-up that trashes an old project takes its change tickets and access requests with it, and after sixty days there is nothing to restore.	Restrict who can trash or delete projects, and treat project deletion as a change requiring approval like any other.
Vulnerability scanner finding history	Varies by product and licence — many tools keep full history only for the current term or a rolling window	First-seen dates are the spine of every SLA test. Lose them and you cannot show when the remediation clock started, only that the finding is closed now.	Export the complete finding set monthly, including closed findings, with first-seen and closure dates, and keep those exports yourself.

Defaults as documented by each vendor at the time of writing, August 2026, on standard configurations. Retention is a per-tenant, per-licence and sometimes per-repository setting and vendors change it — treat this table as the list of things to go and verify in your own tenant, not as an authority on what your tenant does.

The practical rule most organisations land on is the observation period plus fieldwork plus a margin — thirteen to eighteen months for audit-relevant records, longer where a regulator or a customer contract says so. Where a platform cannot be extended, the answer is to export on a schedule and keep the exports yourself, with their parameters and run dates visible. An export you can regenerate is stronger evidence than an archive nobody can explain, so document how each one is produced while you still remember.

Tooling, honestly

What automation platforms do — and where they stop

The category leaders — Vanta, Drata, Sprinto and Secureframe among them — differ in integration coverage, workflow and price, not in the mechanics below. These platforms are genuinely useful and we help clients run them. They are also routinely misread as a substitute for the examination, and the third column is where that misreading bites.

Platform capability	What it actually evidences	The population gap it cannot see
Scheduled cloud and identity-provider polling	That the setting was in the observed state at each poll. Most platforms poll integrations on a cycle — commonly around once every twenty-four hours — so the artefact is the poll result.	The interval between polls. A setting changed and reverted inside one cycle leaves no record in the platform at all; that history lives in CloudTrail or the identity provider’s audit log.
Cloud integration through a scoped read-only role	The configuration state of the accounts you connected, read through an IAM role, service principal or service account you granted.	A second AWS account, a personal GCP project, a self-hosted git server or an unconnected SaaS tenant is invisible. It is not flagged failing — it is absent, and absence renders as compliant.
Endpoint checks through an agent	Disk encryption, screen lock, OS version and agent health on the machines actually running the agent.	An unenrolled laptop is not a failing device; it is not a device. Reconcile the agent roster to HR headcount and the MDM inventory monthly, or your population is whatever the agent happened to find.
Personnel workflows — policy acknowledgement, onboarding, training	Genuine completion records with dates and named individuals. Usually the strongest evidence these platforms produce, and the least disputed.	Only for people the HR integration created. Contractors, agency staff and anyone added by hand and then forgotten sit outside the roster the completion percentage is calculated against.
The built-in check library and its criterion mapping	That the vendor’s check passed against the vendor’s own control wording.	Your Section 4 control text is yours. Where the platform tests something narrower than what you promised, the difference is your exception — reconcile the two before fieldwork, not during it.
Alerting when a check fails	That a check failed and a notification or ticket was raised.	Disposition. Unless someone records what was decided and done, you hold a detection record and no evaluation record — and evaluation is the half CC4.1 is about.
The auditor workspace and evidence-sharing portal	A tidy handover channel. It genuinely shortens fieldwork and reduces round trips.	It is neither an opinion nor a population. The auditor still requests the complete list from your source systems and still traces selected items back to them.

Two things sit underneath the whole table. First, no platform attests: the opinion comes from a licensed CPA firm under AT-C 205, and a green check is a signal to go and look rather than a substitute for looking. Second, evidence a platform derives through an API is still information used as evidence, so the auditor has to satisfy themselves about its accuracy and completeness — in practice by tracing a sample back to the source, comparing the platform’s rendering of a group membership against the identity provider’s own audit event. That is normal, and not a criticism of the tool. One further consequence worth planning for: a platform holding read access to your cloud, identity and endpoint estate is itself a vendor with significant access, which places it squarely inside your own vendor risk management under CC9.2.

Two different questions

Monitoring for compliance vs monitoring for security

These are conflated constantly, including by people selling both. Compliance monitoring asks did the control operate as described? — it watches the control system, and CC4.1 is where it lives. Security monitoring asks is something happening to us now? — it watches the production system for anomalies indicative of malicious acts, disasters and errors, and determines whether they are security events. That is CC7.2, with CC7.3 covering the evaluation of events into incidents and CC7.4 the response.

A control can be green in the compliance tool and useless in the threat model. A security team can be excellent at detection and still have nothing evidencing that anyone evaluated whether the control was present and functioning.

Compliance-only programmes accumulate well-documented controls nobody has tested against a real adversary, and are surprised when a penetration test lands. Security-only programmes run capable detection and cannot produce one artefact showing an alert was triaged, because the disposition lived in someone’s head. The reconciliation is unglamorous: make disposition a recorded step in the security workflow, and treat control performance as data that gets reviewed and minuted on a schedule.

Worked example

Twelve months, three exceptions

An illustrative composite, not a client engagement: a sixty-person analytics platform in its second Type 2, observation period 1 October 2024 – 30 September 2025, Security and Availability in scope. The populations are carried through to the end so the arithmetic is visible.

Oct – Dec 2024

Clean quarter. The access review closes on 14 October, changes flow through protected branches, vulnerability tickets close inside thirty days.

Feb 2025

The engineer who ran access-review campaigns leaves. The Q1 campaign is never opened; the platform’s access-review check is configured as annual and still shows green.

11 May 2025

An incident forces two emergency changes, deployed at 02:14 and 03:40. Approvals are recorded the next afternoon in chat; change tickets are never raised.

Jul 2025

Three high-severity findings first seen in the April scan sit open at ninety-six days against a thirty-day SLA, re-triaged verbally with nothing written down.

2 – 20 Sep 2025

Someone checks the evidence position four weeks before period end. A catch-up review is completed on 20 September covering January to September; retrospective change tickets are raised for May.

Oct 2025 — fieldwork

Populations arrive: 22 leavers, tested in full because the population sits below the sampling threshold; 1,180 production deployments, 25 selected; 4 access-review campaigns, 2 selected and then extended to all 4 once the first deviation appears; 12 monthly SLA reconciliations, 3 selected; 417 scan findings across the period, of which 3 high-severity items aged past the SLA.

How the first exception reads in Section 4

Test performed: Inspected the access-review campaign record maintained in the identity provider for each of the four quarterly reviews scheduled during the period.

Result: For 1 of the 4 quarters selected, no evidence of a completed access review was available. A review covering January through September 2025 was completed on 20 September 2025. Exception noted.

Two sentences, and every argument the organisation might have made is already answered by them. Note what the second sentence does: the catch-up review is not ignored, it is described — and describing it is what makes the nine-month span visible to every reader of the report.

Three exceptions go into Section 4 with management’s responses in the optional Section 5. Whether the opinion is modified is the service auditor’s evaluation of those exceptions against the criteria in aggregate; it is not determined by a count. The causes are what matter: the access review had one owner and no deputy, the emergency path named no approver and set no window, and nothing produced an SLA ageing report. None of the three needed new software. All three needed a calendar entry with a name on it.

Evidence

What the request list looks like after a monitored year

The requested-evidence list usually arrives before fieldwork, organised by control or criterion rather than by team — the first surprise for organisations that filed their evidence by team. If the year was monitored, answering it is retrieval. If it was not, this is the fortnight in which everybody finds out.

Population first

For each control, the complete list of instances during the period and where it came from: every termination from the HR system with export parameters and run date visible, every deployment from the pipeline, every scan result including closed findings. A curated list is not a population.

Completeness and accuracy of that list

Auditors call this IPE — information produced by the entity — and testing the completeness and accuracy of IPE is a required step, not a formality. Expect questions about how the list was produced, what the filter excluded, and what could be missing. For some controls they will observe you generate the export, or re-perform it themselves. Hand-maintained trackers fail here however accurate they happen to be.

Selection, made by the auditor

The sample is drawn by the service auditor from the population you provided, using their own method. You do not choose the months and you cannot swap an item you dislike.

Artefact per selected instance

The system-generated record with its timestamp, who performed and who approved, and the downstream action: a ticket with full state-transition history, an identity-provider audit event, a merge record with its approving review, minutes with attendees and date.

Walkthrough, separately

Early on, the auditor walks the key controls end to end with their owners — normally a subset chosen by risk, not every line in the matrix. A confident walkthrough by the person who actually runs the control shortens everything that follows; one given by a compliance manager describing what they believe happens lengthens it.

Four procedures do the actual work, and knowing which one a control attracts tells you what to instrument. Inspection covers tickets, merge records, campaign exports and minutes, and carries most of a SOC 2. Reperformance — the auditor re-running your access listing or your monthly reconciliation and comparing the result to yours — is common wherever the artefact is a derived list rather than a captured event. Observation covers things that only exist while they happen: a restore test, a physical access check, a walkthrough. Inquiry corroborates the other three and is not sufficient evidence on its own — a control supported only by somebody saying it happened is a control with no evidence, which is why “the team does this every week” never survives contact with a request list.

Rejected on sight

The four that come back from a year you did not monitor

Each of these costs a round trip, and round trips near a report deadline are how a fixable gap becomes a documented one. All four share a signature: the artefact is real, and its date is wrong.

A catch-up review whose single record spans several quarters. One artefact cannot evidence four scheduled occurrences, and the span is legible in the campaign dates.

An approval timestamped after the change it purports to approve — the commonest single finding in change management, and unfixable once both timestamps exist.

Evidence generated after the request date for a control that should have operated months earlier. The creation date records when the artefact was made, not when the control ran.

A dashboard aggregate offered with no per-instance record: ninety-eight per cent of what, drawn from where, and which two per cent.

The wider catalogue of artefacts that get sent back — undated screenshots, exports filtered before they were saved, policies offered as proof of operation, owner-maintained spreadsheets as the only record — is set out in SOC 2 evidence collection.

Where this gets contested

Edge cases that generate the real questions

These are the situations where an early conversation with the service auditor is worth far more than a late one.

A control implemented in month seven

It cannot have operated throughout, and documentation will not change that. Commonly the description and the test state the date from which it operated, and the auditor evaluates whether the criterion was met across the period by the controls that did exist. DC 200 — the description criteria for a SOC 2 — require the description to cover the system throughout the period and to disclose significant changes during it, so the implementation date belongs in Section 3 as well as in the Section 4 test result. Raise it early, not at fieldwork.

Late, but done

The quarterly review closed five days after quarter end. Whether that is an exception depends entirely on wording: “within fifteen days of quarter end” operated as described, while “quarterly” leaves the auditor to decide what quarterly means. Write the tolerance in, and make it one you can meet.

Emergency changes

CC8.1’s points of focus include providing for changes necessary in emergency situations. A defined path — a named out-of-hours approver, a stated window for retrospective documentation, and review at the next change meeting — survives testing. An undefined one produces deployments that read as unapproved, however justified at 02:00.

Evidence that expired before the auditor asked

Ninety-day log retention against a twelve-month period is the quietest failure in SOC 2: the control operated, the record is gone, the test cannot be performed. The retention table above lists the defaults that most often catch teams out. Check every one of them against your own tenant before the period opens, not after.

A tooling migration mid-period

Change identity provider, ticketing system or scanner mid-period and the population splits across two sources. The join is your responsibility and it gets far harder once the old system is decommissioned. Export the full history before cutover and record the cutover date — a migration of this kind is normally a significant change to the system, and DC 200 requires significant changes during the period to be described, so the cutover belongs in Section 3 too.

Risk acceptance instead of remediation

A documented, approved risk acceptance beats silence, but it does not make a control operate. If the control promises remediation within thirty days and you accepted the risk instead, it did not operate as described. Take the exception, then reword the control for next period.

The monitoring platform was connected in month four

A common consequence of buying tooling mid-period: the platform holds evidence from the day the integration was authorised and nothing before it. That is not a gap in the control, only in one view of it — the underlying identity-provider and cloud logs still cover months one to three if retention allowed. Pull those directly, record the connection date, and never let the platform’s own start date become the implied start date of the control.

Two cases sit outside this page. A genuinely empty population — no terminations, no incidents, no emergency changes — is legitimate and reportable, but it has to be evidenced rather than asserted, and it is handled properly in SOC 2 sampling and sample sizes. And controls run by a subservice organisation are not yours to evidence. You must evidence instead that you obtained and reviewed their report, tracked the complementary user entity controls assigned to you, and actually operated them — itself a recurring control that belongs on the quarterly calendar, which is why it has a row in both tables above.

Objection handling

What buyers ask about a year of monitoring

“You claim continuous monitoring, but the auditor tested twenty-five days out of three hundred and sixty-five.”

Sampling is how tests of controls work, in every attestation and every audit — testing every instance of a daily control across a year is not what the standards ask for and not what any firm does. The strength of the result comes from two things the sample size does not show: the population being complete, and the selection being the auditor’s rather than yours. Offer the population reconciliation and the source of the export; more screenshots answer a question nobody asked.

“Your compliance dashboard says one hundred per cent.”

That figure describes the checks the platform is configured to run against the systems it is connected to, evaluated at the last poll. It is a readiness signal and a useful one, but it is not an opinion, it does not cover anything the platform was never connected to, and it says nothing about the eleven months before today. The examination result lives in Section 4, control by control, with the auditor’s test and its outcome written out.

“There is an exception on access reviews in your report.”

Exceptions appear under clean opinions routinely, and a report with none across a first Type 2 is more unusual than a report with two. Three questions are worth asking and one is not. Ask what caused it, what changed structurally afterwards — a deputy named, a campaign scheduled in the tool rather than raised by hand — and whether the following period’s report shows the control operating without exception. Asking whether the vendor is “still compliant” gets you nothing, because the report never said that.

“How do we know anything held after the period ended?”

From the report alone you do not: it speaks only to the stated period, and the day after it ends the report is a historical document. A bridge letter covers a short gap with management’s own representation and carries no audit assurance whatsoever, which is worth knowing before treating one as a substitute. The better answer is structural — the next period is already running, its start date is known, and the monitoring cadence that produced this report did not stop when fieldwork did.

“Does continuous monitoring mean real time?”

No, and the criteria do not ask for it. CC4.1 is satisfied by ongoing and/or separate evaluations; its points of focus, which are considerations rather than requirements, suggest a balance of the two with the ongoing ones embedded in business processes. Nothing in that requires a live dashboard. A monthly reconciliation that always happens and is always written down evidences the criterion better than a real-time view nobody looks at and nobody records a decision from.

Where TCSA fits: we do the readiness, control design, evidence architecture and year-round operating cadence, and we coordinate the examination with an independent CPA firm. We do not certify, attest, audit or sign — the opinion is the CPA firm’s, and it has to be, because independence is what makes the report worth anything to the buyer reading it.

Frequently Asked Questions

Does SOC 2 require continuous monitoring?

The Trust Services Criteria never use the vendor phrase, but the idea sits in CC4.1, which asks the organisation to select, develop and perform ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. Either kind satisfies the criterion. Its points of focus — considerations, not requirements — ask management to include a balance of the two and to build the ongoing ones into business processes. So the requirement is not a product or a dashboard: it is that control performance is evaluated as routine, with a record of the evaluation.

Can we collect SOC 2 evidence at the end of the observation period?

For most controls, no. A Type 2 tests operating effectiveness throughout the period, so what matters is the record created when the control operated. The distinction that matters is between creating a record and extracting one: pulling a full year of identity-provider audit events in the final month is fine, because the underlying events were captured as they happened. Backdating an approval, or running one review in September and calling it four quarterly reviews, is not — the artefact is about the period rather than from it.

What evidence do auditors accept for a quarterly access review?

The campaign record from the identity provider or governance tool: every entitlement in scope, the reviewer for each, the decision, the date it was made, plus the revocation records that followed with their own timestamps. Reviewers should not be reviewing their own access. A spreadsheet can work if it is dated, complete against a system-generated entitlement listing, and paired with evidence the removals happened — but it is weaker, and it fails the moment nobody can say where the listing came from.

Do compliance automation platforms make us SOC 2 compliant?

They keep you ready and remove a great deal of manual collection, but they cannot make you compliant and cannot produce a report. Only a licensed CPA firm performs the examination and issues the opinion, under the AICPA attestation standards at AT-C 205. The auditor still tests the underlying evidence rather than accepting a green check, still needs a complete population from your source systems, and still asks whether the platform monitors what your control descriptions promise. Anything never connected to the platform is invisible to it — and invisible renders as compliant, not as failing.

How much evidence does a Type 2 actually need?

Less than teams fear in volume, more than they expect in structure. The auditor does not want twelve months of screenshots; they want the complete population for each control and then a sample drawn from it — one item for an annual control, two of four for a quarterly one, two to four of twelve for a monthly one, and twenty to forty for a daily control, with twenty-five the usual starting point. What consumes time is provenance rather than quantity: showing where each population came from and demonstrating that nothing is missing from it.

What happens if we miss one quarter of a quarterly control?

The population is four and you can evidence three, so the control did not operate as described for one instance. That is an exception, described in Section 4 alongside the auditor’s test result — and a deviation at that rate usually prompts the auditor to test all four rather than the two originally selected. Whether it affects the opinion is the service auditor’s evaluation of severity in context and in aggregate. Do not attempt a retrospective catch-up review: it does not restore the missed instance and it adds a second, more awkward fact to explain.

How long should we retain evidence and logs for a SOC 2?

Long enough to survive the whole observation period plus fieldwork, which in practice means the period length plus a comfortable margin — many organisations settle on thirteen to eighteen months for audit-relevant records, longer where other obligations apply. The failure to watch for is a default shorter than the period, and the defaults are shorter than most people assume: Okta System Log at ninety days, Entra ID sign-in and audit logs at seven or thirty depending on licence, CloudTrail Event History at ninety, GitHub Actions logs and artifacts at ninety. A control that operated without a surviving record tests identically to one that never operated.

What sample sizes will the auditor use?

The AICPA prescribes no sample sizes for SOC 2; the service auditor determines them from their own methodology. Market convention scales the sample with control frequency: one item for an annual control, two of four for quarterly, two to four of twelve for monthly, five to nine of fifty-two for weekly, and twenty to forty for a daily control operating across roughly 250 business days, with twenty-five the usual starting point. Event-driven populations below about twenty-five items are normally tested in full. Expected deviation rate and assessed risk move all of these numbers.

Why does the auditor question how our exports were produced?

Because a listing you generate is information produced by the entity — IPE in audit shorthand — and the standards require the practitioner to evaluate whether information used as evidence is sufficiently reliable, including its completeness and accuracy. A filter applied before the export, a report definition nobody can explain, or a count that does not tie to a second source all make the population unreliable, and a sample drawn from an unreliable population supports no conclusion. Expect to show the report parameters, the run date, and the query or saved report behind any custom extract.

Who should own year-round evidence in a small team?

Ownership belongs with whoever performs the work, not a central function that chases them: the engineer approving changes owns change evidence, the person running offboarding owns deprovisioning evidence. The central role is smaller — maintain the calendar, run the monthly reconciliations, and check every control still has a named owner and a named deputy. The most common failure in small programmes is a control with one owner and no deputy, which is exactly how a quarter goes missing while somebody is on leave.

Written By Expert Auditors

Surendra Pal Singh

Chief Information Security Officer & Data Protection Officer

CISODPOCISAMCSEITILISO 27001 Lead AuditorISO 27701 Lead AuditorISO 42001 Lead Auditor

Saundhi Chauhan

Lead Auditor

ISO 27001 Lead AuditorISO 27701 Lead Auditor

Last reviewed: August 2026•Content verified by certified lead auditors

Keep Exploring

Get in touch

Book a free consultation or send us your requirements. We respond within 24 hours.

Quick Call

Pick a time slot

Send Requirements

Get a custom quote in 24 hours

We're Online

Continuous Monitoring andYear-Round Evidence