Working to more than one framework

You have one program. A framework is a view of it.

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 in three spreadsheets, with the same control written three times in three dialects.

Kanonik is built the other way round. You have one program. A framework is a view of it.

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 framework at the same thing.

The frameworks Kanonik works with

There are 17:

• SOC 2
• ISO/IEC 27001
• HIPAA
• GDPR
• NIST CSF 2.0
• NIST SP 800-53 Rev. 5
• NIST SP 800-171 Rev. 2
• NIST SP 800-171 Rev. 3
• FedRAMP Rev. 5 baselines
• GovRAMP Rev. 5 baselines
• CCPA/CPRA
• DORA
• NIS2
• NYDFS Part 500
• EU AI Act
• NIST AI RMF 1.0
• NIST SSDF

SOC 2, ISO 27001 and HIPAA are the audited frameworks. NIST CSF 2.0 and GDPR are included on every plan, and one audited framework comes with Audit-Ready. Another audited framework is $3,000 a year. Your compliance work runs on the AI you already pay for, so we don't charge you for one. No per-user fees, no per-questionnaire fees.

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. The other frameworks on the list 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 reason a second framework takes far less work than the first.

The frameworks overlap heavily because they are all describing sensible security practice from different angles. Your access control policy 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 accurate, because 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" starts 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. Suggestions are counted and shown separately, and 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.

When a suggested connection reaches you for approval, the approval card shows why it was suggested, next to the control and the requirement:

• Crosswalk from names the connection you already approved, with its framework and clause title.
• Crosswalk reading says whether the published relationship fully or only partly covers the requirement. Where it is partial, Not covered states that the source clause covers only part of the requirement.
• Why suggested gives the short reason the relationship's author recorded, when there is one.

These rows appear only when Kanonik can find the relationship in the loaded framework; the connection is checked again when you approve it either way.

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:

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

The framework you start with is the hard one. The next is mostly recognition.

Related

• 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. For anything else, email [email protected] and a person who works on the product answers.