Proving your controls cover your requirements.

A control that is written and approved is not yet proof that you meet a requirement. The proof is the connection between the two: a reviewed, recorded statement that this control satisfies that requirement. This article explains what that connection is, why Kanonik asks you to approve it rather than assuming it, and how to read your coverage so you are never surprised by a gap.

Every framework has a coverage statement

Whatever framework you work to, there is one document an assessor lives in: the one that lines up each requirement against the controls you rely on to meet it. In ISO 27001:2022 it is the Statement of Applicability. In SOC 2 it is the control matrix against the Trust Services Criteria. For a US federal authorisation it is the System Security Plan. GDPR has its records of processing and its measures; HIPAA has its safeguards mapping; PCI DSS has its report on compliance. Different names, same backbone: requirement, the control that covers it, and whether that control is actually in place.

Kanonik builds this coverage picture for you from the connections you approve. Add more frameworks later and the same connections light up each new framework's view, because a single good control usually satisfies several frameworks at once.

Declaring is not the same as proving

When your AI drafts a control, it will note which requirements the control is meant to address. That is useful, but it is intent, not proof. "This control was designed to cover that requirement" is the author's opinion. What an assessor asks for is different: "You claim this control meets that requirement. Who decided that, and when?"

That second statement is a decision your organisation makes and stands behind. It can be wrong. A control can look like it covers a requirement and not really do so, or cover only part of it. So Kanonik treats the connection as its own reviewed decision, not as something that happens automatically the moment a control is written. The control knowing its requirements is the starting point. The approved connection is the finish line.

Why you approve each connection

Each connection between a control and a requirement is checked and then put in front of you to approve, the same way a new control or policy is. This is deliberate. The connection is an assertion you may have to defend in an audit, and for some frameworks it carries legal weight. A connection nobody reviewed is the kind of thing an assessor pulls on first, and if they find it was never checked, they start to doubt the whole statement.

This is also where Kanonik is stronger than tools that let you bulk-tick hundreds of mappings with no record of who agreed to them. Every connection here is reviewed, attributed to a person, time-stamped, and locked into a tamper-evident record. That is what makes your coverage statement hold up.

To keep this from becoming a chore, Kanonik proposes the connections for you. When you approve a control that is meant to cover several requirements, the matching connections are prepared automatically and brought to you together, so you confirm them in one place rather than remembering to create each one by hand. You still get to see each one, and to wave off any that are not right, before you approve the rest.

Reading your coverage: three states, one that counts

For each requirement, your coverage view shows one of three things:

• Covered. A connection to a control has been approved. This is the only state that counts as real, assured coverage, and the only one that appears in the statement you would hand to an assessor.
• Awaiting you. A connection has been prepared and checked but you have not approved it yet. This shows you what is ready to confirm. It is kept separate on purpose and is never counted as coverage until you approve it.
• Gap. The requirement applies to you and nothing covers it yet.

The point of keeping "awaiting you" separate from "covered" is accuracy. You should never look at your coverage and believe a requirement is handled when the connection is still sitting unconfirmed.

Coverage is more than a single connection

Two more things shape an accurate coverage picture, and Kanonik keeps them separate from the connection itself:

• Some requirements do not apply to you, and that is allowed. A requirement with no control is not automatically a failing. It may genuinely not apply, for example physical-security requirements when you run no facilities of your own. Marking a requirement as not applicable, with a reason, is its own recorded decision, so your statement explains the blanks instead of showing false gaps.
• One control is often not enough. A single requirement can need several controls working together. Your coverage reflects whether a requirement's full set of controls is in place, not just whether one of them is, so a partly covered requirement does not read as finished.

In short

A requirement is covered when you have approved a connection from a control to it, not when a control merely claims it. Kanonik prepares those connections for you, checks them, and asks you to confirm, so your coverage statement is complete, clear about what is still pending, and able to stand up when someone asks who decided what.

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.