When we started building Tenurex, one of the first things we did was go back through our notes from the SOC 2 audit prep cycle we'd run at a previous company. The spreadsheet we'd used to track evidence collection had a last-modified date from about four days before the auditor arrived. Nearly everything we'd "documented" as a control had been scrambled together in that final week.
That's point-in-time compliance in practice. Not a philosophy — a fire drill that gets dressed up as a program.
This post is about what actually distinguishes continuous monitoring from the annual audit model, why the gap matters more than most GRC discussions acknowledge, and where continuous monitoring genuinely struggles (because it's not a cure for everything).
What Point-in-Time Audits Actually Test
A SOC 2 Type II audit covers a period — typically 12 months. The auditor selects a sample of days within that window and asks: were the controls you described in your system description actually operating on those days? Did access reviews happen? Did log monitoring run? Did change management tickets get created?
The implicit assumption is that if controls were operating on the sampled days, they were probably operating throughout the period. This is statistically reasonable. It's also where the model starts to show cracks.
Point-in-time thinking — treating the audit as the compliance checkpoint rather than a verification of an ongoing state — means that teams often have controls that are only "operating" when someone is paying attention. Access reviews get completed because the audit is coming. Encryption configurations get checked because the auditor asked. Vendor risk reviews happen because the questionnaire listed them.
Between those moments? The controls may or may not be running. Nobody knows, because nobody's watching.
The Drift Problem Nobody Talks About
The technical term for what happens between audits is control drift. A configuration changes in a deployment and the encryption-at-rest flag gets reset to default. An engineer leaves and their access isn't revoked because the offboarding ticket went stale. A new AWS region spins up for a customer but the CloudTrail logging policy wasn't extended to cover it.
None of these are catastrophic individually. Each one is a small drift event. But drift accumulates, and the problem with point-in-time audits is that they don't catch accumulation — they catch only the state on the day they sample.
Consider a scenario we've seen reflected in how teams describe their audit experiences: a growing SaaS company at roughly $3M ARR, eight engineers, a dedicated compliance manager. They pass their SOC 2 Type II for year two. Eleven months later, while prepping for year three, the compliance manager runs a manual access review and finds that fourteen former contractors still have read access to the production database — access that had been provisioned during a product sprint eighteen months earlier. None of the sampled days in year two happened to fall on a day when someone ran that specific access check.
The drift had been there for over a year. The audit didn't catch it because point-in-time sampling doesn't catch gradual accumulation. Continuous monitoring would have caught it within the first rotation cycle after the access was provisioned.
What Continuous Monitoring Actually Means (Operationally)
Continuous monitoring isn't a philosophy — it's a specific operational pattern. It means that the state of your controls is being checked at a regular cadence (not just when the auditor asks), and that deviations from expected state generate alerts before they turn into findings.
In practice, this requires a few things working together:
- Integration with evidence sources. Your identity provider, cloud infrastructure, ticketing system, HR system, and endpoint management all produce signals that are relevant to your control state. To monitor continuously, those signals have to be ingested continuously — not exported to a spreadsheet once a quarter.
- Control-to-criterion mapping. A raw log from AWS CloudTrail doesn't tell you whether your CC7.2 control is operating. You need a layer that maps that raw signal to a specific control, and that control to a specific Trust Service Criterion, so you know what you're actually monitoring.
- Gap detection with signal clarity. When a control drifts, you need to know: which control, what changed, when it changed, and what criterion it affects. A generic security alert that says "IAM policy changed" isn't a compliance gap notification — it's noise. You need specificity to act on it.
- Evidence retention in audit-ready format. Every check that runs — whether the control passed or flagged a gap — needs to be retained as evidence. When the auditor asks "was MFA enforced on October 14th?" the answer should be queryable in seconds, not reconstructed from memory.
Where Point-in-Time Still Has a Place
We're not saying annual audits are useless. They're not. They serve a specific function that continuous monitoring can't fully replace: external attestation.
When a prospect asks for your SOC 2 report, they're asking for an independent third-party opinion that your controls were operating as described. A continuous monitoring dashboard is valuable internal evidence, but it doesn't carry the same weight as a CPA firm's opinion letter. The market has settled on formal audits as the trust mechanism for B2B compliance attestation, and that's not going away.
The right mental model is that continuous monitoring is what you do between audits so that audits stop being fires. The audit itself becomes a verification of a state that you've been maintaining continuously — not a reconstruction of a state you're hoping you can prove.
What this means practically: when your next SOC 2 Type II window opens, you're not scrambling to collect evidence because evidence has been collecting itself. Your auditor asks for access review logs from March 15th. You pull them in thirty seconds. They ask about MFA enforcement on April 3rd. You show them the continuous check log. The sample days aren't terrifying because every day looks the same.
The Evidence Format Question
One detail that comes up in practice: auditors have opinions about evidence format. Raw API call logs are technically accurate but not audit-friendly. What auditors want to see is structured evidence — a clear chain of custody showing what was checked, what the result was, what the source system was, and when the check ran.
This is where the distinction between "we have logs" and "we have compliance evidence" becomes important. Logs are data. Compliance evidence is logs that have been structured, timestamped, attributed to specific controls, and retained in a way that an auditor can review without a three-hour tutorial on your infrastructure.
When we built the evidence collection pipeline at Tenurex, we spent a lot of time on this format problem. The goal wasn't to produce more data — it was to produce evidence that a Type II auditor could pick up and immediately understand which control it supported and what the result was on a given day.
The Honest Tradeoff
Continuous monitoring requires upfront integration work. You have to connect your identity provider, your cloud accounts, your ticketing system — and that integration has to be maintained as your stack evolves. It's not a one-time setup. New AWS regions need to be added. New SSO apps need to be monitored. New employee cohorts change your access review scope.
The tradeoff is that this ongoing maintenance cost is much lower than the periodic scramble cost. A 6-week audit prep cycle at a company with three people involved in compliance is roughly 360 person-hours. If continuous monitoring reduces that to a 3-day final review and evidence export, you're recovering most of that time — every year.
For a team our size — we're four people, and compliance is everyone's job part of the time — the math of continuous monitoring made obvious sense. We weren't going to maintain a manual compliance program alongside building a product. We needed evidence to collect itself and gaps to surface themselves. That's what we built, and it's what we use.
The annual audit isn't going away. But the 6-week scramble before it should be.