A control is one requirement in a framework. For each control you show what satisfies it (the evidence), who is responsible for it (the owner), how well established it is (maturity) and when it was last confirmed (the review). This guide covers working with a single control.
To open a control, go to Frameworks, select View on an active framework and select the control in the list. Controls you own are also listed under My controls in My Workspace (see My Diri).
The details panel shows Status, Maturity, Owner, Next review due and Last verified. Some controls also show whether they are Mandatory, Conditional or Optional, and the kind of evidence the control expects (Policy, Record, Technical or Interview).
The status follows the evidence linked to the control:
Each linked item counts as implemented when it reaches the end of its own workflow:
| Evidence | Counts as implemented when |
|---|---|
| Policy | The policy is Published. A draft or a policy in review keeps the control short of satisfied. |
| Task | The task is closed. |
| Risk assessment | The risk assessment is approved. |
| Treatment | The treatment is set to Implemented (or Not applicable). |
| Other items (for example files, external links and application resources) | You set the Implementation status on the item yourself: Not started, In progress or Implemented. |
A treatment that is not applied in any risk assessment has its status set directly on the control, and the change saves immediately. Once the treatment is applied in an assessment, its status follows that assessment.
Select Open on a linked item to view it. To remove an item, select Disconnect; the control's progress is recalculated without it.
You can also link from the other side: policies, tasks, treatments, risk assessments and DPIAs have a Control tags field. Adding a control there links the item to the control. Business process activities can also be linked to controls (see Business processes).
Set the Owner in the details panel. The owner receives a notification and the control's review reminders, and finds the control under My controls. Only people in the organisation can own its controls. A control without an owner sends no review reminders, so these are counted under Needs a decision on the Frameworks page. Reassigning ownership is restricted to administrators.
Maturity describes how well established the control is, on the CMMI scale. It never affects coverage.
| Level | Meaning |
|---|---|
| None | The control is not performed. No practice is in place. |
| Initial | Performed ad hoc and reactively, depending on individual effort rather than an agreed way of doing it. |
| Managed | Planned and performed with responsibility assigned and resources allocated, but practice still varies between teams or systems. |
| Defined | Standardised and documented as an organisation-wide practice, and applied consistently wherever relevant. |
| Optimised | Measured against objectives and improved on that basis, so the practice adapts as the organisation changes. |
The framework's Implementation depth only counts controls that are satisfied or in progress.
Under Applicability (administrators only):
Both are stamped with who set them and when.
A review is someone confirming that the control still holds. Satisfied controls should be reviewed regularly so the confirmation stays valid.
The review states are Never reviewed, Up to date, Due soon (within 30 days), Overdue and Requirement changed (the requirement was rewritten after the last review). A control also counts as overdue if its evidence changed after it was last verified. An overdue review does not change coverage.
The next review date is set from the organisation's Control review cycle, which administrators set in Settings. Individual controls can have a shorter cycle where the risk warrants it. Upcoming control reviews appear on the Annual Wheel as control attestations, and the owner receives reminders.