Governance
The governance layer holds the reference objects — the documents and catalog items your assessments are built on. Unlike the operational objects you author yourself, reference objects arrive ready-made, are read-only, and are shared by every domain in the instance.
The four reference objects
Section titled “The four reference objects”- Frameworks — published standards such as ISO/IEC 27001:2022 or NIST CSF, broken down into a tree of requirements. A framework is the input to every audit; the audit spawns one requirement assessment per requirement in it.
- Threats — a catalog of things that can go wrong, used to build risk scenarios. Importing an established threat catalog gives your risk work a shared vocabulary; you can still create custom threats when the catalog falls short.
- Reference controls — generic, best-practice control definitions. They act as templates and vocabulary for your own applied controls: an applied control can point at the reference control it instantiates, which powers suggestions and cross-framework consistency. This is the decoupling of compliance and implementation in miniature — the reference control describes the idea, the applied control describes what you actually run.
- Risk matrices — the lookup tables that turn a probability and an impact rating into a risk level. Every risk assessment is bound to one matrix. Most organizations standardize on a single official matrix, though CyberGuard lets you pick per assessment; changing the matrix after scenarios have been rated means reviewing those ratings, so choose deliberately.
Libraries: the delivery vehicle
Section titled “Libraries: the delivery vehicle”Reference objects do not enter CyberGuard one by one — they arrive bundled in libraries, YAML packages imported from Governance → Libraries. A library typically carries one primary object (a framework, say) plus its companions: a framework alongside its reference-control catalog and a mapping to a sibling framework. Libraries can declare dependencies on one another, and importing a library pulls in what it depends on.
Two states matter:
- Stored — the library is known to your instance and visible in the catalog, but its content is inactive.
- Loaded — the library has been imported. Its frameworks become available when creating audits, its threats appear in the threats list, its matrices in the matrix picker.
Library content is identified by URN — a stable identifier that survives renames and re-imports, which is what lets audits keep pointing at the right requirements over time. Libraries are versioned, and can be upgraded in place when a new revision of a standard ships. CyberGuard bundles a large built-in catalog, and you can author custom libraries for internal frameworks or control sets that never leave your organization.
Policies
Section titled “Policies”Governance is also where organizational policies live. In the object model, a policy is a specific type of applied control — a document describing what is expected of your stakeholders. Keeping policies in CyberGuard makes them readily available to compliance assessments and puts their lifecycle (owner, review date, status) under management like any other control.