Overview

CyberGuard is built from a small set of object families that reference each other. Understanding how they fit together makes every screen in the product more predictable: the same few objects — domains, frameworks, applied controls, evidences — keep reappearing wherever you work.

Four layers

• Organization — domains and perimeters define where work lives and who can see it. Every other object is attached, directly or through a parent, to a domain.
• Governance — reference objects define what you assess against: frameworks, threats, reference controls and risk matrices, all delivered through libraries. They are read-only catalog material, shared across the whole platform.
• Risk — risk assessments and scenarios describe what could go wrong, how likely and how damaging it would be, and what you are doing about it.
• Compliance — audits and requirement assessments measure how well you satisfy a framework, requirement by requirement, with evidence attached.

Applied controls at the center

The object tying the layers together is the applied control — anything your organization actually does to manage risk or prove compliance: a technical safeguard, a process, a documented policy, a tested recovery plan. Describe it once, and the rest of the platform connects to it:

• An audit links each requirement assessment to the applied controls that satisfy it.
• A risk scenario lowers its current and residual levels through the applied controls in place and planned.
• Evidence attached to an applied control substantiates every requirement and every scenario that control supports.
• An incident response invokes applied controls; a policy is a specific kind of applied control.

The decoupling principle

The corollary is that everything around applied controls stays decoupled, so one object can serve many consumers without being rewritten:

• Controls are decoupled from compliance requirements. A single applied control — say, your backup process — can satisfy requirements in ISO/IEC 27001, NIST CSF and a customer questionnaire simultaneously. Compliance describes what must hold; implementation describes what you run; CyberGuard links the two instead of merging them.
• Risk assessments are decoupled from frameworks. The same risk scenario can inform several compliance audits; risk work is never trapped inside one standard.
• Assets are decoupled from scenarios. Assets exist independently of any specific risk study and are reused across them.

The payoff is reuse end-to-end: one control answers many requirements, one assessment covers many frameworks, one evidence file substantiates everything the underlying control supports. When you wonder where a piece of information belongs in CyberGuard, the answer is usually “on the applied control” — and everything else points at it.

Tip

This decoupling is why importing a second framework into an existing workspace is cheap: the audit is new, but the applied controls and evidences it draws on already exist.

Reading order

The following pages describe each family in turn: Organization, Governance, Risk, and Compliance. If you prefer learning by doing, the quickstart builds one object of each kind in about fifteen minutes.