Mappings

Most organizations answer to several standards at once — ISO 27001 plus SOC 2 plus something sector-specific. Without mappings you re-assess the same posture against each standard’s requirement list, which is busywork. A mapping (or crosswalk) records how the requirements of one framework relate to those of another, so you assess once and project the result onto the next framework.

Where to find it

Catalog → Mappings in the sidebar.

Key concepts

Mapping sets

The object on this list is a mapping set: one source framework, one target framework, and the individual requirement-to-requirement links between them. Like frameworks, mapping sets arrive as libraries — the import shortcut takes you to Libraries filtered to mapping content. Many common crosswalks ship ready to load; where none exists, a mapping set can be authored as a library.

The list is intentionally plain: Source framework and Target framework, filterable by provider. What matters is inside.

Relationship types

Each link carries a relationship type, easiest to read as a set relation between what the two requirements cover:

Type	Meaning	Carries over?
Equal	Equivalent in scope and intent	Fully
Superset	The source requirement is broader than the target	Fully
Subset	The source requirement is narrower than the target	Partially — review needed
Intersect	They overlap, neither contains the other	Partially — review needed
No relationship	Disjoint	Nothing

Direction matters. A mapping from A to B does not imply B to A, and reversing one usually inverts the relationship — a subset becomes a superset.

The graph explorer

The explore button on the mappings list opens a graph view of the crosswalk. It is the fastest way to answer questions the table cannot: which requirements have no counterpart at all, where coverage is thin, and which parts of the target framework a source audit will never reach. Use it before committing to a projection, not after.

Projecting an audit

Mappings earn their keep when you create a new audit and choose to map from an existing one:

Create the audit on the target framework and select Map from an audit.
Pick the source audit. If no crosswalk connects the two frameworks, CyberGuard says so rather than guessing.
A preview compares the current state of the new audit against the projected state, requirement by requirement, marking each as full coverage or partial coverage and listing the results, scores, observations, applied controls and evidences that would be carried across.
Confirm mapping applies it.

Requirements filled from a full-coverage link land complete. Partial ones are filled and flagged, because a subset or intersect relationship means somebody has to read the target requirement and decide whether the source answer really satisfies it. Treat the projection as a very good first draft, not a finished audit.

Mapping suggestions also appear while working inside an audit: where a loaded crosswalk covers the requirement you are on, CyberGuard tells you an answer exists elsewhere.

Chained mappings

You do not need a direct crosswalk between every pair of frameworks. If mappings exist from A to B and from B to C, CyberGuard chains them and projects an A audit onto C, using B as a pivot — even though nobody ever authored an A-to-C crosswalk. The target picker already lists every framework reachable this way.

Two things to know about chains:

Coverage degrades to the weakest hop. One partial link anywhere in the path makes the whole projection partial.
Depth is bounded. The Mapping max depth setting in General settings limits how far the search goes, defaulting to 3 and raising to 5. Longer chains find more matches but produce progressively more indirect — and less defensible — inferences.

Frameworks — the two ends of every mapping.
Audits — where a projection lands.
Libraries — where mapping sets are loaded from.