Where your controls come from

Good controls start with your risks, and the framework is the check that nothing was missed.

There are two ways to end up with a set of controls. You can look at a framework's list and write something for each line. Or you can work out what could actually go wrong in your business and build the controls that prevent it, then use the framework to check you have not missed anything. Kanonik is built around the second approach, because that is what the standards ask for and what assessors expect to see. This article explains the difference and why it changes how a control is checked.

The short version

A control exists to reduce a risk. A framework requirement exists to make sure you have not overlooked a category of risk that experience says organisations tend to overlook.

So the order is:

Your environment, then your risks, then the controls that treat them, then the framework check.

Working the other way round, writing one control per line of a checklist, tends to produce a set of documents that map perfectly and protect very little. Assessors recognise it quickly, and it is the most common reason a programme looks complete on paper and fails in practice.

What the standard actually asks for

This is not a stylistic preference. ISO 27001 sets out the order directly in its clause on risk treatment. You determine the controls necessary to treat the risks you assessed. Then you compare that set against Annex A to verify that no necessary control has been omitted. Then you produce your Statement of Applicability.

Annex A comes second, and its job in that sequence is to catch omissions. It is a checklist for completeness, not a catalogue to copy.

Other frameworks are organised differently but land in the same place. SOC 2 states criteria and expects you to define the controls that meet them for your business. NIST CSF describes outcomes rather than controls. In each case the framework tells you what has to be true, and you decide what to operate to make it true.

The part most people get backwards

There is an asymmetry here that explains a lot:

• A requirement with no control is a gap. Something the framework says must be addressed is not addressed. That is a finding, and it needs an answer.
• A control with no requirement is normal. Plenty of sensible controls treat a business risk that no framework happens to name. That is not a deficiency, and no assessor will record it as one.

The obligation runs from requirement to control, not the other way. Your framework coverage has to be complete. Your control set does not have to be exhausted by the framework, and in a healthy programme it usually is not.

This is why Kanonik does not push you to attach every control to a requirement. Some of your best controls will exist purely because you decided a risk was worth treating.

How this changes the way a control is checked

Because controls arrive from two directions, there are two different questions worth asking about one, and Kanonik keeps them separate.

Is this a sound control? Does it say who is responsible, how often it runs, what it applies to, and what counts as it failing? Could an assessor design a test it could fail? This question applies to every control from the moment it is drafted, whatever it was written for.

Does this control cover the requirement it claims? This only makes sense once the control claims something. Until then there is nothing to check it against.

A control that treats a risk and names no requirement is complete work. It gets checked for soundness, and that is the right check. It is not marked down for failing to satisfy a requirement it never claimed, because being asked to prove a claim you did not make is not something an assessor would ever do.

Once you connect that control to a requirement, the second question becomes live, and the connection is checked on its own terms. That connection, and why it is approved separately, is covered in Proving your controls cover your requirements.

What you will see

When your AI proposes a control during risk work, expect it to be tied to the risk it treats. That link is the point of the control, and it is what closes the gap that prompted it.

When you later work through a framework, your AI will connect your existing controls to the requirements they satisfy, and surface the requirements nothing covers yet. Those are your real gaps. Often a control you already built for your own reasons turns out to satisfy several requirements at once, across more than one framework.

Both directions end in the same place: a coverage picture built from connections you reviewed and approved, and a control set that exists because of decisions you made about your own business.