Help center
Keeping your compliance current.
Compliance is a living program. Here is how changes, reviews, and continuous evidence work.
Compliance is never a one-time project. It is a living program. Your risks change, your controls evolve, your policies get updated. This article explains how you change things in Kanonik, how the history is kept, how often you should be reviewing, and what all this means for a SOC 2 Type 2 audit.
How you change things: nothing is edited, everything is recorded
The most important idea: in Kanonik you never quietly overwrite anything. Every change is a new, approved decision recorded on top of the old one, and the previous state stays on the permanent record. You can always answer the auditor's question "what did your program look like on this date?", because nothing is ever erased.
That applies across the board:
- Risks have a life of their own. A risk starts as identified, becomes treated once a control is protecting against it, can be accepted when you formally sign off on whatever residual risk remains after treatment, and is retired when it no longer applies. To re-score a risk (say its likelihood went up after a change in your environment) or to change how you are treating it, your AI proposes the update, the safety check runs, and you approve it. The new state takes effect and the earlier one stays in the history.
- Policies are versioned. When a policy needs to change, your AI drafts the new version, it passes the safety check, you approve it, and the new version supersedes the old. The prior version remains in the record, so you can show an auditor exactly what was in force and when.
- Controls evolve the same way. Your AI proposes the updated control, you approve it, and the prior state stays on the record. You also maintain the links between things, which control treats which risk, which control implements which policy, adding or removing them as your program matures. Each of those is its own approved, recorded decision.
- Accepting residual risk is always a human decision. After a risk is treated, if some risk still remains and you, as the risk owner, judge it acceptable, you formally accept it. Kanonik confirms you are the owner and that the residual is no worse than before treatment, but the judgment is yours, and it is recorded with your approval.
Because the whole history is preserved, you get time travel for free: you can look at your risks, controls, and policies as they stood at any past moment, which is exactly what auditors and incident reviews need. See Your program as it stood on any date.
How often should you review and update?
Three rhythms, and the first one matters most.
Continuously: driven by change, not the calendar
Anything that changes your real environment should trigger an update right away, not at the next scheduled review:
- a new vendor or a new system
- a new type of data you start handling
- a security incident or a near-miss
- an organizational change (new owner, departed staff, new scope)
- a control that stopped working
These are the updates that keep your program accurate. Kanonik captures each one as it happens, with a timestamp and your approval, so the record reflects reality continuously rather than in quarterly bursts.
Quarterly: operational review
Every quarter, confirm your controls are still operating: access reviews done, evidence still fresh, owners still accountable. Re-score any risks whose likelihood or impact may have shifted. This is the cadence that catches drift before it becomes a finding.
Annually: full refresh
At least once a year, do a complete pass: refresh the full risk assessment, review every policy (most frameworks expect policies to be reviewed at least annually), and confirm your scope, ownership, and framework coverage are all still correct.
Rule of thumb: scheduled reviews are the floor, not the ceiling. A major change always wins: reassess now, do not wait for the next quarter.
What this means for SOC 2 Type 2
It helps to be precise about the difference between the two SOC 2 report types:
- SOC 2 Type 1 asks: is your control design adequate at a single point in time? It is a snapshot.
- SOC 2 Type 2 asks: did your controls actually operate effectively over a period of time? The auditor picks an observation window, commonly six to twelve months, and samples evidence from across that whole window to confirm your controls ran consistently, not just on the day of the audit.
Type 2 is the harder, more credible report, and it is almost always what enterprise customers want to see. The thing it demands is continuous evidence: proof that your controls were operating, and your program was being maintained, throughout the period, captured as it happened, not reconstructed the week before the audit.
This is exactly the shape of how Kanonik works. Because every decision, approval, and change is recorded continuously on a permanent, tamper-evident timeline, you accumulate the running evidence trail a Type 2 audit samples from, with clear answers to who approved what, and when, across the entire window. The practices above (capture change as it happens, review quarterly, refresh annually) are precisely what produce a clean Type 2 result.
To put yourself in the best position for a Type 2 audit:
- keep controls operating continuously, and let Kanonik record each operation and approval as it happens
- log your quarterly and annual reviews as you do them, so the cadence itself is evidenced
- record exceptions and changes with their approvals, rather than letting them live in email
- when the audit window opens, you are not scrambling for evidence; you are exporting a record you have been building all along
A note on framework coverage: Kanonik runs SOC 2 (Trust Services Criteria) today, alongside ISO 27001:2022, GDPR, and NIST CSF 2.0. The mechanics that make Type 2 evidence work (the continuous record, the approvals, the time travel) operate the same way for every framework you activate.
More help
Browse every article in the Help center, where you can also ask the Kanonik assistant directly. For anything else, email [email protected] and a person who works on the product answers.