Skip to main content

Obligations

Obligations are binding or otherwise important commitments that your organization has made to other parties. Typically, they are the "interpretation layer" where compliance managers use judgement to document what frameworks mean to your organization.

G
Written by Gagan

Obligations Overview

Obligations are created by compliance managers interpreting how the requirements of a framework apply to their organization — normally phased in business-friendly language that aligns with your organization's terminology.

In this way, obligations are a product of a specific framework and can only be connected to a single framework in Essential Compliance. Frameworks can have many obligations (1:n relationship).

An obligation can have multiple sub-obligations and a sub-obligation can only have one parent (1:n relationship). Multiple levels of sub-obligations can be created.

Example: Under the Canadian AML statute (PCMLTFA), a financial institution might identify an obligation called "Client identification and record-keeping," outlining the information they need to track for every customer account.

Obligations Console

The Obligations Console is the main screen for viewing and managing all your obligations. It features:

  • Dashboard tiles at the top showing summary percentages (compliant %, partially compliant %, etc.) that update based on active filters

  • A filterable table grouped by framework, with expandable/collapsible rows showing sub-obligations

  • Filters for: Theme, Owner, Framework, Portfolio, Record Status, and Compliance Status

Console Actions

Action

Who Can Do It

Create Obligation or Sub-Obligation

Admin and Standard users

Edit/Delete/Merge Frameworks

Admin users only

Edit, Delete, Move Obligation

Admin and Standard users (subject to permission settings for standard users deleting resources)

Obligation Details Screen

Click on any obligation to open its details screen. Key sections include:

Summary Section

  • Name, Owner, Description — Standard fields

  • Record Status — Draft, Active, Inactive, or Archived (this is separate from Compliance Status)

  • Version — Optional text field (e.g., "1.2 Canada")

  • Sub-Obligation Badge — If this obligation is a child of another, a badge appears linking to the parent

  • Authoritative Citation — Side-by-side view with Official Citation, Authoritative Text, Guidance, and Source Link fields on the left and your Interpretation on the right

  • Adoption From / Adoption Until — Optional date fields for tracking when the obligation applies

Compliance Status Box

Displays the overall compliance status of the obligation, calculated automatically based on its attached key resources (AKRs): sub-obligations, policies, and must-have controls. Also shows:

  • % of compliant active policies

  • % of compliant active must-have controls

  • % of compliant active sub-obligations

Users can manually override the auto-calculated status using the "set value" link, and reset it back to the automatic calculation at any time.

Configurable Sub-Sections

Admin users can configure which sub-sections appear on the details screen. Available sub-sections include:

  • Sub-Obligations, Policies, Controls, Risks, Indicators, Objectives, Incidents, Action Plans, Notes

Associations

Shows linkages between the obligation and its related frameworks and themes. Click Manage Associations to create or break these linkages.

Other Sections

  • Materiality Scoring — Score obligations using materiality factors and scoring systems configured by admin users and assigned through portfolios. Materiality scoring can be used to prioritize obligations and/or to document why some obligations are not material to the organizations (and will not be actively managed).

  • Risk Heat Map — Plots residual risk scores for risks attached to the obligation (appears only when the Risks sub-section is enabled).

  • Change Log — Tracks all changes to the obligation.

Sub-Obligations

Obligations support parent-child hierarchies in a 1:n relationship. This means that an obligation can have many sub-obligations, but a sub-obligation can only have one parent. For example, a broad obligation can be broken into more granular sub-obligations, similar to how objectives work. Multiple levels of sub-obligations can be created.

Sub-obligations:

  • Inherit their parent's framework

  • Can be in different portfolios from their parent

  • Appear indented in the console tree view

Did this answer your question?