Skip to content
Kanonik
Menu
Help
Browse Help
On this page

Your program as it stood on any date

Every fact carries two dates. That is what lets you prove the past, not reconstruct it.

Most of the time, you look at your compliance program the way it is right now: what is covered, what needs you, what your AI just proposed. That is the right view for getting the work done. But there are moments when the question is a different one, and that difference is where this part of Kanonik earns its keep.

When an auditor or a regulator asks, or something goes wrong, the question is what was true on a particular date, and whether you can prove it. Kanonik is built to answer that, because every fact on your record carries two dates, not one.

The two dates on every fact

For everything in your program, a control, a risk, a piece of evidence, a decision, Kanonik records two separate moments:

  • When it took effect on the record. For most changes, the moment they were approved. For a piece of evidence, the date it was collected, as your AI reported it.
  • When Kanonik wrote it to the record. The moment it landed on your tamper-evident timeline.

In a spreadsheet, or in most compliance tools, you get one date, and you can change it. Here you get both, and neither can be quietly rewritten. That single difference is what makes everything below possible.

Why it matters, in practice

You can show your program as it stood on the audit date. Auditors do not look at today. They sample your history across the audit period and ask what was in place then. A tool that only shows the current state forces you to reconstruct the past by hand, from screenshots and memory. Kanonik reconstructs it for you: set the date to the audit period, and the whole workspace shows what was true and what you had recorded as of then, not a tidied-up version assembled after the fact.

Your evidence is trusted because a backdated entry shows. The oldest move in compliance is backdating: entering a control during the audit and claiming it was in place months earlier. In Kanonik most changes are dated when they were approved, and that date cannot be set earlier. Evidence carries the date it was collected, as your AI reported it, next to the date it was recorded, so a document collected in February and recorded in March reads as exactly that. Your genuine, on-time work is believed without an argument, because the record shows when each thing was recorded.

You can correct a mistake without looking like you are hiding one. You will misrate a risk or misclassify a control at some point. In a tool where editing overwrites the old value, a change made at audit time looks suspicious: what did you alter, and why. Kanonik keeps both what you assert now and what you previously asserted. A correction is a new entry that points back at the one it replaces, and the earlier entry stays in the record, which is exactly what a careful program does.

Period-based and continuous audits become answerable. SOC 2 (Trust Services Criteria) and ongoing monitoring are not point-in-time checks; they ask whether a control operated for the whole period under review. Because any date can be reconstructed, proving that a control was in force throughout a window stops being manual archaeology and becomes a question you can answer directly.

Where you will actually meet this

You will not think about this every day, and you are not meant to. Your daily view is your readiness and what needs your attention. This capability lives quietly behind an "as of" date control, ready for the moments that call for it: an audit, a regulator request, an incident review asking whether a control was in place when an event happened.

That is the practical value. It is less a feature you reach for and more a property of your record. When scrutiny arrives, you can show what your program was on the date that matters, and show that you did not change it afterward.

More help

Browse every article in the Help center. For anything else, email [email protected] and a person who works on the product answers.