Working to more than one framework

Most organisations end up carrying more than one framework. You start with the one a customer asked for, then a second lands in a security questionnaire, then a regulation applies to you whether you asked for it or not. The usual result is three parallel programs, three spreadsheets, and the same control written three times in three dialects.

Kanonik is built the other way round. You have one program. A framework is a lens you look at it through.

Your record is not shaped like any one framework

This is the idea everything else follows from, so it is worth a paragraph.

Underneath, Kanonik does not store an ISO program or a SOC 2 program. It stores your actual estate: your risks, your controls, your policies, your evidence, and the reviewed connections between them. A framework is a set of requirements you load on top of that, and a coverage view is what you get when your estate is read through those requirements.

That is why adding a framework is not a migration. Nothing about your record changes shape when a second framework arrives. You are pointing a new lens at the same thing.

The frameworks available today

Four are loaded and ready to work against:

ISO/IEC 27001:2022 (Annex A)
SOC 2 (AICPA Trust Services Criteria, 2017, as revised 2022)
GDPR (Regulation (EU) 2016/679)
NIST Cybersecurity Framework 2.0

You choose which one you are looking at from the framework control at the top of your workspace and your Statement of Applicability. Switching is a read: it re-derives that framework's view of your estate. It never edits anything and it never asks you to re-enter work you have already done.

ISO 27001 and the SOC 2 criteria are copyrighted standards, so you need your own licensed copy of the text. Kanonik asks you to confirm you hold one before it will build an audit export against those two, and your workspace settings hold that confirmation. GDPR and NIST CSF 2.0 are public documents and carry no such step. This is a small piece of paperwork that keeps you, and us, on the right side of the standards bodies.

One control usually satisfies several frameworks

This is the leverage, and it is the reason a second framework costs far less than the first.

The frameworks overlap heavily because they are all describing sensible security practice from different angles. Your access control policy is not an ISO artifact that happens to help with SOC 2. It is a real thing your organisation does, and ISO 27001:2022, SOC 2, and GDPR each ask about it in their own language. Write it once, review it once, and connect it to each framework's requirement.

So when you add a framework, the question is rarely "what do we need to build?" It is usually "what do we already do, and where does it land in this new vocabulary?" Most of the answer already exists in your record.

Coverage is read one framework at a time

Each framework has its own coverage picture, and each one is derived from the connections you approved against that framework's requirements.

Kanonik counts a requirement as covered only when two things are true: you have decided the requirement applies to you, and the control you connected to it is actually implemented. A control that is connected but not yet in place is not counted as coverage. It shows as assigned, with the work still open.

This is deliberate, and it is stricter than it needs to be. A connection says "this control answers this requirement". It does not say the control exists in practice. The failure that hurts in an audit is the one where the programme looks covered and the artifact is empty, so the number only moves when the work is genuinely done. It can under-report your position. It will not flatter it.

The consequence to expect: switching to a framework you have not worked yet shows a lot of gaps. That is not the tool being pessimistic. It is telling you the truth, which is that your organisation has not yet asserted anything about that framework. What you did for ISO 27001:2022 is real work, and much of it will carry, but carrying it is a decision you make rather than something that happens quietly.

Why nothing is credited across frameworks on its own

The tempting shortcut is obvious. You covered ISO 27001:2022 Annex A 8.7, the published crosswalks say it lines up with SOC 2 CC6.1, so mark CC6.1 green and move on.

Kanonik will not do that, and the reason matters more than the feature.

A coverage statement is something you defend. When an assessor samples a connection and asks who decided that this control satisfies this criterion, "the software inferred it from a mapping table" is not an answer. It is the beginning of a much longer conversation about everything else in the statement. One unreviewed connection can put the whole document in doubt.

There is also a plainer problem. Crosswalks are approximate. Two requirements can look equivalent in a table and differ in scope in a way that matters to your organisation specifically. A control that fully answers the ISO wording might cover only part of the SOC 2 criterion. Only someone who knows your estate can make that call.

So the rule is the same rule as everywhere else in Kanonik: a connection between your control and a requirement is a decision your organisation makes, it is checked before it reaches you, and you approve it. Fast is fine. Automatic is not.

Suggested connections

Kanonik makes the second framework quicker in a way that respects the rule above rather than working around it.

The framework packages carry the published relationships between requirements. Kanonik uses them to suggest connections you have not made yet: where you have already approved a control against a requirement in one framework, and that requirement is known to line up with a requirement in the framework you are looking at now, that control is offered as a likely answer, with the reasoning attached.

Three things are true of those suggestions:

A suggestion is not coverage. It is counted and shown separately, and it is never added to your coverage number. Nothing changes in your position until you confirm.
Confirming one is an ordinary approval. It runs the same check and needs the same click as any other connection. What you save is the typing, not the judgement.
Where the published relationship is partial, the suggestion says so, and says what it does not cover, so a partial match cannot quietly become a full claim.

The record ends up stronger than a hand-typed connection, not weaker. A connection made this way carries where it came from: the reviewed connection it was derived from, the published relationship that linked them, and the versions of both frameworks at the time. An assessor sampling it sees a documented derivation that a named person then reviewed and approved.

The practical order of work

If you are about to take on a second framework:

Switch to it and read the gaps without flinching. That list is your scope.
Ask your AI what you already have that answers each requirement. Your existing controls are in the record and it can read them.
Approve the connections that hold. Decline the ones that do not, and let them stand as real gaps rather than talking yourself into them.
Build only what is genuinely missing, which is usually far less than the initial gap list suggests.

The first framework is the expensive one. The second is mostly recognition.

Proving your controls cover your requirements. What a connection is, and why each one is approved rather than assumed.
Why you approve every change. The rule that makes the record defensible.
Exporting your evidence for an audit. What an assessor receives.

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.

Working to more than one framework.