Frameworks

The Frameworks module is where you tell Novantra which compliance frameworks your organization actually has to follow. It is the place you record their structure (sections, controls, requirements), pin yourself to a specific version, and connect each requirement to the work in your workspace that satisfies it.

You’ll typically set this up once per framework, then revisit when a new version is published or a new framework is added to your obligations.

When you would reach for this

You set up frameworks when:

A regulator, certifying body, or customer requires you to demonstrate compliance with a published standard.
An internal policy needs to be tracked as a framework alongside external ones.
You’re rolling out a new version of a framework you already follow and need both versions visible during the transition.
You’re adopting a parent framework’s structure as a starting point for organization-specific addenda.

You don’t reach for this when capturing evidence or assigning controls to people. Those are separate modules, related to but distinct from the framework itself.

What lives in a framework

Four kinds of record, building on each other:

Framework - the top-level entry. Has a name, a short identifier you choose, and an optional description and source reference.
Framework version - a specific published version of the framework. A framework can have many versions; only one is typically “current” at a time, but older versions stay readable for historical assessments.
Framework nodes - the hierarchical structure inside a version: domains, sections, sub-sections, individual controls or requirements. Nodes can nest as deeply as the framework’s own structure does. Each node has a reference code (the framework’s own identifier) and a title.
Coverage links - the bridge between a node and the work in your workspace that satisfies it. A coverage link says “this requirement is implemented by this control” or “this requirement is evidenced by this evidence claim.” One node can have many coverage links; one piece of work can satisfy many nodes.

A worked example: a regional hospital network

A multi-site hospital network operates under three frameworks at once: an international information security standard, a sector-specific healthcare data-handling standard, and an internal patient-data policy. Their compliance lead, Layla, sets up Frameworks like this.

Step 1: register each framework. From Governance → Frameworks, Layla creates three top-level records. Each gets a stable key she picks (info-sec, healthcare-data, internal-patient-policy), a name, and a one-paragraph description so colleagues understand the scope.

Step 2: pin a version for each. Under each framework she creates a version representing the exact wording she’s responsible for at this moment in time. For the internal policy, the version is the date her board approved it.

Step 3: lay in the structure. For each version, Layla adds the framework’s own structure as nodes. She doesn’t have to enter every single control on day one; she starts with the domains and the controls she knows are in scope for the next quarter’s work, and adds more as the team needs them.

Step 4: link coverage. Once she has nodes in place, she goes to Controls and creates a “Patient record access review” control, then comes back here and creates coverage links from the relevant nodes in all three frameworks to that one control. The single control now demonstrates coverage of three frameworks at once.

A year later, the international standard publishes a new version. Layla creates a new version under the existing framework. Old assessments stay tied to the previous version (historically accurate); new work attaches to the new one. The framework itself doesn’t move; only the versions evolve.

What you’ll see in the product

Frameworks lives under Governance → Frameworks in the workspace.

The Frameworks list shows everything you’ve registered, with status filters. Click into a framework to see its versions.

Inside a framework, you see its versions in a list. Click into a version to see the framework’s hierarchical structure, expandable node by node.

Inside a version, the Nodes tab shows the hierarchy. The Coverage tab shows every coverage link out of nodes in this version, so you can see at a glance which requirements are connected to actual work and which aren’t.

Every change you make is captured in the workspace Audit Log with the actor, the change, and the reason you provided.

Source kinds

When you create a framework or a version, you can mark its source kind as regulator, standard, internal, customer, or any other label that reflects where the framework comes from. This is free text on your side; the product doesn’t impose a fixed list. It’s useful for filtering: “show me only regulator-issued frameworks” when a regulator audit is approaching.

Coverage roles

A coverage link carries a role explaining how the target work covers the framework node. Roles include:

implements - the target control or work directly implements this requirement.
evidences - the target evidence record demonstrates compliance with this requirement.
informs - the target work informs or maps to this requirement without fully satisfying it.
supersedes - the target replaces this requirement in your organization’s current posture.

Roles let you express the precise relationship; one control might implements one framework’s section and informs another framework’s adjacent section simultaneously.

Common workflows

Adopting a new framework

Frameworks → New framework. Pick a stable key, a name, and capture the published source.
Inside that framework → New version. Add the version label and source.
Add nodes representing the parts of the framework you’ll operate against. Start with the top-level structure; deepen as needed.
Go to Controls (or other relevant modules) and create or link the work that will satisfy those nodes.
Return to the version’s Coverage tab and create coverage links.

Upgrading to a new version

Find the existing framework in the list.
Add a new version under it.
Copy or recreate the nodes that exist in the new version.
Reuse existing controls where the new version’s requirement still maps; create new ones where it doesn’t.
Older assessments remain tied to the old version, preserving the historical record.

Decommissioning a framework

Mark the framework as retired (preserves history; stops it from appearing in active selection lists).
Existing coverage links and assessments tied to it remain visible.
Retirement is the cleanest exit; the framework’s history stays intact.

Looking for the API?

See Frameworks API reference for the v1 REST endpoints to list frameworks, versions, nodes, and coverage links from an external system.

Controls - the work you’d link a framework requirement to.
Evidence - records demonstrating compliance with a framework requirement.
Assessments - evaluating a control or requirement against a framework.
Submissions - packaging compliance evidence for a regulator.