Point-in-Time Compliance Is Dead: Why Your Evidence Has to Be Continuous

Continuous compliance means your controls produce evidence as a by-product of running, not as a project you launch six weeks before an audit. The difference is not philosophical. A point-in-time audit tells you a control worked on the days the auditor sampled; it says nothing about the other three hundred and forty.

That gap used to be acceptable because everyone lived with it. It is becoming less acceptable, for a practical reason: your customers now ask about controls between audits, and your own AI systems change faster than an annual cycle can track.

What does point-in-time actually miss?

Consider a control most Canadian SaaS companies have: access is removed within one business day of an employee leaving. In a SOC 2 Type II examination, the auditor pulls a sample. Say twenty-five terminations across the period. All twenty-five look clean. You pass.

Now the honest question. Between those twenty-five, how many contractors kept a login for four months? The sample did not include contractors. The control was scoped to employees, the report says the control operated effectively, and both statements are true. The risk sits entirely in the space the sample did not cover.

This is not an argument that audits are worthless. They are the only independent check most organizations get. It is an argument that the audit is a measurement, and a measurement taken twice a year is a poor way to run anything you actually care about.

What "continuous" means in practice

It does not mean real-time dashboards for everything. It means three specific properties.

Evidence is generated, not gathered. If proving a control requires someone to take screenshots, the control is not continuously evidenced. If the same proof falls out of a system log, a ticket, or an approval record automatically, it is.

Failures surface when they happen. An access review that runs quarterly finds a problem up to eighty-nine days after it started. A check that runs nightly finds it tomorrow. Same control, different exposure window.

The register of controls is live. Someone can ask "how many of our controls are currently passing" and get a number that is true today, not a number from the last assessment.

Here is the same programme viewed both ways.

Note that nothing in the right column requires new tooling. It requires the trigger to move from a human's calendar into a system.

Where do you start if the programme is manual today?

Pick the controls that fail quietly. That is the whole selection rule.

Some controls fail loudly. If backups stop running, someone notices during the next restore. Others fail in silence for months: stale access, an unreviewed vendor, an assessment that was never opened, a retention rule nobody applied. Silent failures are where continuous monitoring earns its cost, so start there and ignore the rest for now.

For each one, write down two things. What is the signal that this control is working, and where does that signal already exist? Most of the time the signal exists and nobody is reading it. Your identity provider already knows who has access. Your ticketing system already knows what was approved. The work is connecting them, not creating them.

A practical sequence that has worked for teams under fifty people:

1. Access. Join your HR leaver list against active accounts, nightly. This one control catches more real risk than the next five combined.
2. Vendors. Put renewal and review dates into a system that opens a task, rather than into a spreadsheet somebody has to remember to open. Our vendor inventory does this by date.
3. Assessments. Make a new high-risk system automatically open a privacy impact assessment instead of relying on someone to file one.
4. Incidents. Log every incident, including the ones that turn out to be nothing. A register with only real breaches in it looks fabricated to an auditor.
5. Retention. Turn your retention schedule into scheduled deletions rather than a document describing deletions.

What does this change about the audit itself?

The audit gets cheaper and more honest.

When evidence accumulates continuously, the pre-audit scramble mostly disappears. You are not reconstructing nine months of approvals from memory and email. More importantly, you stop discovering control failures during the audit, which is the worst possible moment to discover them.

There is a second effect that matters commercially. Enterprise buyers increasingly ask for evidence between certification dates, and they ask through security questionnaires. A programme with live control status answers those in hours. A programme with an annual report and a spreadsheet answers them in a week, badly. If you sell to enterprises, that difference shows up in your sales cycle before it shows up in your audit.

Is continuous compliance overkill for a small company?

For a ten-person company with no certifications and no enterprise customers, yes, probably. The honest threshold is your first serious buyer or your first regulated data type. Before that, a well-maintained spreadsheet and a real quarterly rhythm is a defensible programme, and you should not let anyone tell you otherwise.

Past that threshold, the calculation flips fast. The cost is not the tooling. It is that manual compliance quietly consumes a senior person for several weeks a year, and produces a worse result than an automated check that runs while everyone sleeps.

If you are earlier in the journey, SOC 2 for Canadian companies covers what buyers are actually asking for and when it becomes worth pursuing.

This is general information, not legal advice.

Valdra was built around the continuous model: controls carry live status, assessments open themselves when a system qualifies, and the evidence trail accumulates in the background. The SOC 2 readiness view shows what that looks like against a real framework.