Skip to content

Multi-level frameworks

Many frameworks organise their requirements into tiers — a basic set, then progressively more demanding ones. CIS calls them implementation groups, CyFun calls them assurance levels, FedRAMP calls them baselines. CyberGuard models all of them with one generic mechanism: implementation groups. Picking the groups that match your ambition means an audit that contains only the requirements you are actually committing to, instead of a long list you have to mentally filter every time you open it.

On the audit creation form, right under Target framework. If the chosen framework defines implementation groups, a Selected implementation groups field appears; if it does not, the field is simply absent. The same field appears when you create an entity assessment, so a supplier questionnaire can be scoped the same way.

Pick one or more groups. They combine — selecting two groups gives you the union of their requirements, which is what you want for the cumulative frameworks where each tier builds on the one below.

Leave the field empty and the audit starts with every requirement in the framework. That is the safe default when you are still deciding: an over-broad audit can be narrowed later, whereas a too-narrow one quietly hides the requirements you forgot to ask for.

The selection is not frozen at creation. Edit the audit and change Selected implementation groups at any point to widen or narrow the scope. Requirements that leave the scope stop being shown and stop counting towards progress; their answers are not destroyed, so bringing a group back restores the work already done on it.

Some frameworks are dynamic: an answer inside the audit decides which tier applies, so the implementation group is derived from your responses rather than picked up front. On those, the field carries a note — answer-driven groups are recomputed on save, while groups you selected by hand are kept. In practice that means you can still pin an extra group manually, and the framework’s own logic will add or remove the answer-driven ones around it as the assessment progresses.

Because the scope can change mid-flight on these frameworks, a requirement revealed by a late answer appears in the audit at that moment rather than at creation. Expect the requirement count to move, and re-check progress after answering a scoping question.

Before committing, open the framework in Catalog → Frameworks and look at its implementation groups definition. It lists each group with its label, so you can see what you are signing up for without creating a throwaway audit first.