Obligations

The Obligations module is where your organization keeps the register of everything it has to do. Laws and regulations create obligations. Customer contracts create obligations. Internal policies create obligations. Frameworks you’ve adopted create obligations. Each one is a thing someone has to deliver, demonstrate, or maintain, and each one needs an owner, a status, and a paper trail.

Most large organizations have hundreds of obligations spread across legal, compliance, security, privacy, procurement, and operations. Obligations is the single register where every one of them lives, so when an auditor asks “show me your obligation X and prove you’re meeting it,” you can answer in one click.

When you would reach for this

You set up obligations when:

• A regulator publishes a rule and you need to capture it as something your organization is bound by.
• A customer contract includes specific deliverables, audit rights, breach-notification requirements, or service levels you must honor.
• An internal policy creates a recurring requirement (e.g., “all employees complete annual security training”).
• A framework you’ve adopted breaks down into specific obligations beyond its catalog of controls.
• You need a single authoritative list of “things we are required to do” that a board, an auditor, or a new compliance hire can read end to end.

You don’t reach for this when implementing or assessing the work itself; that lives in Controls, Evidence, and the operational modules. Obligations is the requirement; the other modules are the work.

What lives in an obligation

Two record types:

1. Obligation is the requirement itself. It carries a name, a stable key, a description, an obligation kind (regulatory, contractual, policy, internal, etc.), an owner (responsibility assignment), a source reference (the law, contract, or document the obligation comes from), and an implementation projection that summarizes whether the obligation is currently met.
2. Obligation links connect the obligation to the work that satisfies it: controls that implement it, evidence claims that demonstrate it, risks tied to it, exceptions or findings against it, audit packages that include it. Links carry a role describing how the linked record relates to the obligation.

Obligation kinds

When you create an obligation, you mark it with a kind describing what kind of obligation it is. Common kinds:

Kind is free text; use the label that fits how your organization classifies obligations.

A worked example: a pharmaceutical manufacturer registers its obligations

A pharmaceutical manufacturer produces prescription drugs across two product lines (oncology and respiratory) and ships to multiple operating markets. Their compliance team needs to maintain a single register of every obligation: regulatory submissions, quality management requirements, pharmacovigilance commitments, customer contract terms, and internal SOPs.

Their head of compliance, Sara, sets up Obligations like this.

Step 1: kickoff the register. Sara works through each of these sources:

• The two regulatory frameworks the company operates under (international good manufacturing practice and a pharmacovigilance standard) become regulatory obligations, one per leaf requirement that matters.
• Each major customer contract (the wholesale distributors, the hospitals, the procurement bodies) is reviewed for specific deliverables; each becomes a contractual obligation.
• The company’s internal SOPs (batch-record retention, deviation reporting, supplier qualification) become policy obligations.
• The voluntary sustainability commitments the company has made publicly become commitment obligations.

Step 2: name an owner for each. Each obligation gets a responsibility assignment naming the accountable owner. Regulatory obligations go to the compliance team. Contractual obligations are split between sales operations (delivery commitments) and quality (audit rights). Policy obligations sit with the policy owners. Voluntary commitments sit with the chief sustainability officer.

Step 3: link to the implementing work. For each obligation, Sara creates obligation links to:

• The controls that implement it.
• The evidence requirements that need to be collected to demonstrate it.
• The risks that materialize if the obligation isn’t met.
• The submissions that fulfill it (for reporting obligations).

Step 4: applicability where useful. For obligations that don’t apply to every part of the business (e.g., a pediatric-formulation requirement that only applies to one product line), Sara records an applicability decision limiting the obligation’s scope.

Six months later, a regulator asks for a list of the obligations the company is subject to under one of its operating standards, with current implementation status and the documentary evidence. Sara filters Obligations by kind: regulatory and the source framework, exports the list, and the implementation projection on each obligation tells the regulator at a glance which obligations are fully met, partially met, or under remediation.

Link roles

Obligation links carry a role describing how the linked record relates to the obligation. Common roles:

What you’ll see in the product

Obligations lives under Governance → Obligations in the workspace.

The Obligations list is your obligation register: every obligation with its kind, owner, current implementation status, and source. Filter by kind, owner, status, source framework, or scope.

Inside an obligation, you see:

• The full description and source reference.
• The current implementation projection (met, partially met, not met, deferred, unknown).
• All linked records, grouped by role.
• The audit history of changes.

From here you can navigate to controls, evidence, risks, exceptions, findings, and submissions related to this obligation, and back.

Every change is captured in the workspace Audit Log.

Implementation projection

Each obligation has an implementation projection field summarizing its current status. The projection is computed from the linked controls, evidence claims, exceptions, and findings; it answers “right now, are we meeting this obligation?” at a glance.

Common projection values:

• met - the obligation is currently being met with active implementing controls and current evidence.
• partially-met - some implementation is in place; gaps exist.
• not-met - no implementation in place, or all implementation has lapsed.
• deferred - the obligation applies but implementation is intentionally postponed (linked to an applicability decision).
• unknown - implementation status hasn’t been assessed yet.

The projection is the headline you see in dashboards and reports; the underlying links are the detail.

Common workflows

Registering a new obligation

1. Obligations → New obligation. Pick a stable key, name, kind, and capture the source.
2. Assign an accountable owner.
3. Add an obligation link for each control, evidence requirement, risk, or submission that addresses this obligation.
4. Update the implementation projection as the linked work matures.

Walking the obligation register before an audit

1. Filter Obligations by the framework, kind, or scope the auditor is examining.
2. For each obligation, click through to see the linked controls and evidence.
3. Export the filtered list with the implementation projection column.
4. Address any not-met or partially-met obligations before the auditor arrives.

Handling an obligation that no longer applies

1. From the obligation, create an applicability decision with kind not-applicable, providing justification.
2. The obligation remains in the register for historical accuracy.
3. The implementation projection updates to reflect that the obligation is no longer active.

Decommissioning an obligation

1. Mark the obligation as archived, providing a reason.
2. Existing links and the audit trail remain visible for historical context.
3. The obligation no longer appears in active selection lists.

Related

• Frameworks - frameworks generate obligations.
• Controls - controls implement obligations.
• Evidence - evidence demonstrates compliance with obligations.
• Risks - risks threaten obligations.
• Applicability - decisions about whether an obligation applies.
• Submissions - submissions deliver fulfillment of obligations.