Your program as it stood on any date.

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 sits down, when a regulator asks, or when something goes wrong, the question is not "what does your program look like today." It is "what was true on a particular date, and can you 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 became true in your environment. The date a control actually took effect. The date a risk was formally accepted. The date a piece of evidence was collected.
• 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 the record cannot be faked. The oldest move in compliance is backdating: entering a control during the audit and claiming it was in place months earlier. Because Kanonik keeps both the date a thing took effect and the date it was written down, a late entry shows up as a late entry. The effective date may say February while the recorded date says March. The benefit is the opposite of what you might expect: once the system makes a late entry obvious, your genuine, on-time evidence is believed without an argument. The same property that would expose a shortcut is what vouches for everyone who did the work properly.

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, with the date you corrected it. The correction is recorded as a correction, 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. 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, where you can also ask the Kanonik assistant directly. For anything else, email support@kanonik.ai and a person who works on the product answers.