Associated Obligations

What are associated obligations?

Associated obligations let you track multiple instances of the same commitment separately. For example, a contract might require compliance quarterly reports. Instead of treating that as one ongoing task, Ironclad creates an associated obligation for Q1, another for Q2, and so on. Same goes for event-driven obligations: if you're required to notify a vendor of subprocessor changes, each actual change triggers its own associated obligation.

Why? Because each instance has its own due date, status, and assignee. This gives your team visibility into what's due and who's responsible. But more importantly, it gives you the data you need to ensure timely compliance with your contractual commitments. Can you reliably deliver on Q1, Q2, Q3 when they're due? On the vendor side, that same data shows you their track record. Are they meeting their obligations on time? That's the information you need to decide whether to renew, renegotiate terms, or make changes in a future contract.

Associated Obligations with a Recurring Trigger

A recurring obligation is used for commitments that happen on a schedule, such as monthly reports, quarterly reviews, or annual certifications.

For these obligations, Ironclad stores the recurrence rule on the parent obligation and generates associated obligations for the individual occurrences. In other words, the parent says what must happen and when it repeats, while the associated obligations are the dated occurrences users complete.

Recurring obligations use trigger-specific settings such as frequency, start date, end rules, and due date offset. The due date offset determines when each generated occurrence is due relative to its period, such as a report due a set number of days after quarter end.

See Figure 1 below for a recurring reporting example. The same tracking model applies whether the obligation is quarterly or annual.

Associated Obligations with a Conditional Trigger

A conditional obligation is used when work only starts after a real-world event happens, such as an SLA breach, subprocessor change, force majeure event, or security incident.

In this model, the parent obligation stores the trigger rule or trigger description. When the event occurs, an associated obligation is created to track that specific instance.

This is useful for obligations like subprocessor notices or breach notices because the same contractual obligation may need to be fulfilled multiple times over the life of a contract. Each triggered instance can then be tracked separately with its own due date, status, assignee, and detail view.

How does the information roll up to the parent obligation?

For recurring and conditional obligations, the parent obligation is the rule or source record. The associated obligations are the actionable occurrences. Because of that, the parent does not function like a standalone task with its own independently managed due date and status.

Instead, the parent obligation’s status is derived from its associated obligations.

The same is true for due date. For recurring and triggered obligations, the parent due date is a roll-up from the associated obligations, and the parent-level due date field is not editable.

In practice, that means:

• the parent obligation gives users the rule and the roll-up view
• the associated obligations give users the individual instances they update
• the Dashboard shows the next soonest due date from those instances, rather than a separate manually maintained parent due date