Obligations
Not everything you're on the hook for comes from a framework. A customer contract promises a four-hour incident notification. A regulator requires annual penetration testing. The board directed that privileged access be reviewed quarterly. Your own policy says vendor reviews happen before renewal.
None of those are CMMC or ISO controls, and all of them are real commitments somebody will eventually ask you to prove. The Obligations tab is where they live.
What belongs here
Obligations come from five places:
- Contracts — commitments made to customers in an MSA, DPA, or SLA.
- Regulations — statutory or sector requirements outside your activated frameworks.
- Customer promises — commitments made in a questionnaire response, a security addendum, or a sales conversation.
- Board directives — decisions taken at board or executive level.
- Internal policies — commitments your own policies make.
Map each one to a control
An obligation on its own is a note. An obligation mapped to a control is operational: it shows how the promise is actually kept, and it inherits that control's evidence, status, and assurance.
That mapping is the whole point of the tab. When someone asks "how do you meet the four-hour notification commitment in our contract?", the answer isn't a paragraph — it's a control, its evidence, and when it was last verified.
An obligation with no control behind it is a promise nobody is operating. Those are worth finding before a customer or regulator finds them for you, and they're the reason to keep this list honest rather than aspirational.
Obligations answer questionnaires too
Because obligations carry their mapped controls and evidence, they feed the same foundation the rest of the platform draws on. A commitment you've recorded and mapped is available when a questionnaire asks about it — see How AI answers are grounded.
How this connects
- Controls are what an obligation maps onto — see Assess controls.
- Evidence proves the control behind the obligation — see Evidence overview.