Skip to content
CyberGuardCyberGuard Docs

Compliance

The compliance layer is where you measure your organization against the standard of your choice. Its chain is short: a framework defines the requirements, an audit evaluates a scope against that framework, and one requirement assessment per requirement holds the verdict, the score and the supporting material.

Framework

Section titled “Framework”

The fundamental compliance object is the framework — a given standard, such as ISO/IEC 27001:2022, imported from a library. Frameworks are read-only catalog content: the audit never modifies the standard, it records your position against it. If no published framework fits, you can build your own as a custom library.

Some frameworks ship with implementation groups — named subsets of requirements such as maturity tiers or applicability slices. Selecting groups on an audit narrows the assessable scope to the requirements you have actually committed to.

Audit

Section titled “Audit”

An audit (a compliance assessment) pairs one framework with one domain, optionally narrowed to a perimeter. On creation, CyberGuard spawns a requirement assessment for every requirement in the framework — evaluating a requirement inside an audit is called a requirement assessment. Each one captures several dimensions without conflating them:

  • Result — the compliance verdict: Compliant, Partially compliant, Non compliant, or Not applicable. This is what feeds the compliance percentages and the audit report.
  • Status — the analyst’s workflow state: To do, In progress, In review, Done. A requirement can be Compliant yet still In review; splitting the two keeps “work remaining” and “compliance achieved” as separate, honest numbers.
  • Score — an optional maturity rating on the framework’s scale, recording how deep the implementation is rather than just whether it exists. Scoring can be split into an implementation score and a documentation score, averaged into the maturity figure.
  • Applied controls and evidences — the substantiation, described below.

The audit’s progress figure tracks assessed requirements — an auditing-activity signal, not a compliance one. An audit can be 100 percent worked through and still largely non compliant; the compliance picture lives in the result roll-ups.

Evidences

Section titled “Evidences”

An evidence justifies the status of a compliance requirement or proves that a control has been implemented. It can be a description, a link, or an uploaded file, and it can be attached to any number of requirement assessments or applied controls. Because evidence attaches to the applied control rather than being copied into each audit, one artifact — a configuration export, a signed policy — substantiates every requirement the control supports, in every audit, at once.

The audit lifecycle

Section titled “The audit lifecycle”

A typical audit runs: create it from a framework, assign requirements to their owners, work each requirement from To do to Done while recording results and attaching controls and evidence, review, then report. Requirement assessments left Not applicable are excluded from compliance ratios. The audit remains live after the report — re-running the cycle periodically against the same framework is how you track drift, and the decoupled controls mean the second pass is mostly review rather than re-authoring.

Section titled “Related”