Frameworks

A framework is a structured body of requirements an audit is measured against: an industry standard such as ISO/IEC 27001 or NIST CSF, a regulation such as NIS2 or GDPR, a contractual baseline such as CMMC or SOC 2, or your own internal standard. Every audit in CyberGuard instantiates exactly one framework, so what is available here determines what you can assess.

Where to find it

Catalog → Frameworks in the sidebar.

Key concepts

Frameworks arrive as libraries

You do not type a framework in. Frameworks are packaged as libraries and loaded into the platform, which is why this page has an import shortcut rather than an add button — it takes you to Libraries, where you browse what is available, preview the content, and load what you need. CyberGuard ships with a large built-in catalog covering most international standards and regulations; when none of them fits, a framework can be authored as a library and loaded the same way.

Once loaded, a framework is read only. That is deliberate: an audit trail is only meaningful if the yardstick did not move. Customisation happens on the audit — scoring, applicability, implementation groups — not on the framework itself.

The requirement tree

A framework is a tree of requirement nodes. Some nodes are assessable — the concrete requirements you evaluate one at a time — and the rest are sections and chapters that organise the tree. Creating an audit turns every assessable node into a requirement assessment carrying its own result, score, observations and evidence.

Requirements can also suggest reference controls. When a framework carries those links, creating an audit can propose the applied controls that satisfy each requirement instead of leaving you to invent them. See Reference controls.

Scoring scales

A framework declares its own default scoring scale — a minimum, a maximum and optional level names. A maturity-style framework might use 0 to 5, another 1 to 4, another a percentage.

Individual requirements can override that default when a standard mixes shapes in the same tree, for example a mostly maturity-based framework that also contains a handful of binary pass or fail requirements. The override is resolved field by field: a requirement that names its own minimum, maximum or label set uses it, and otherwise inherits the framework’s.

Roll-ups keep mixed scales comparable. Average-based aggregation normalises each requirement against its own effective range before computing a parent or overall score, then renders the result on the audit’s scale.

An audit copies the framework’s scoring definition when it is created, so the audit stays self-contained and later tweaks to its scale do not break anything.

Fields on the list

The list shows the framework Name and Description, its Provider (who publishes it), the number of Audits already running against it, and the Domain it was loaded into. Filters cover provider and domain, which is how you find one framework among a hundred.

Working with frameworks

Open a framework to inspect its tree before committing to it — the requirement count and depth tell you how much work an audit will be. Check the Audits column before removing anything: a framework in use by an audit cannot simply be dropped.

Multi-framework programmes

Most organizations answer to several standards at once. Rather than assessing the same posture repeatedly, load a mapping between them and project one audit onto another framework — reusing the requirement assessments where the mapping is strong and flagging the rest for review.

Libraries — where frameworks are browsed and loaded.
Audits — what you create from a framework.
Mappings — cross-walks between frameworks.
Reference controls — the control templates requirements point at.