devguard

Controls

Controls are security measures, safeguards, or policies that organizations implement to protect their assets and ensure compliance with frameworks and regulations.

Overview

Controls are the centerpiece of your compliance program in devguard: every framework is built on its controls, and fulfilling these controls determines whether you meet compliance requirements.

They provide the practical foundation for achieving compliance. Whether you rely on devguard’s official frameworks or extend the platform with your own custom frameworks, controls ensure that every compliance requirement is structured, trackable, and reportable.

Core Functionality

Controls are listed within their associated frameworks and can be filtered by name, identifier, or framework for easier navigation. For official frameworks, devguard provides controls directly as part of the maintained standard. These cannot be modified, but you can map them to assets, policies, or risks to demonstrate compliance coverage.

You can also create your own controls and assign them to custom frameworks. This is particularly useful when working with client-specific requirements, internal guidelines, or country-specific regulations not included in official frameworks. Unlike official frameworks, custom frameworks (and their controls) are fully editable.

Each control includes the following information in the overview:

  • ID / Identifier – a structured identifier like 5.7 or NC-1
  • Name – a descriptive title such as Threat Intelligence
  • Framework – which framework the control belongs to
  • Type – Clause, Control, Requirement, Safeguard, etc.
  • Coverage – the current coverage status (Unknown, Partial, Full)

Coverage is calculated automatically based on how the control is linked to policies, assets, or risks. Once all necessary references are mapped, the coverage moves to Full.

Fields Explained

FieldDescription
FrameworSelect the custom framework the control belongs to. Controls cannot be added to official frameworks. (required)
Control NameThe descriptive name of the control (e.g., "Information Security Policy"). (required)
Control IdentifierA unique identifier such as 5.1 or AC-12. (required)
Control TypeDefines the type of control. Options: Control, Requirement, Safeguard, Objective, Category, Group.
DescriptionA free-text explanation of the control’s purpose and scope.
Mandatory ControlMark whether this control is required for compliance with the associated framework.

Best Practices

  • Map every mandatory control to at least one asset, risk, or policy to demonstrate coverage.
  • Use consistent identifiers when creating custom controls to keep reports clean and structured.
  • Do not duplicate official controls in your custom frameworks. Instead, adopt the official framework and map accordingly.
  • Leverage control types (Control, Requirement, Safeguard, etc.) to organize and categorize your compliance implementation.
  • Track coverage regularly: use the Coverage feature to identify gaps and ensure your compliance posture remains strong.

Example

  • Adding a custom control for a client-specific contractual obligation (e.g., “Client data must be encrypted using AES-256 at rest”).
  • Creating an internal objective control to track implementation of Zero Trust policies not yet part of an official framework.
  • Assigning a mandatory safeguard to ensure periodic password resets across your organization.

Applicability

A framework lists every control it knows; your organization implements the ones that apply to it. When a control does not (a company with no software development has nothing to say about secure coding), open the ⋯ menu on its row or the action menu on its detail page and choose Mark as not applicable, then give the justification an auditor will ask for. The control leaves your coverage figures and is listed, with that justification, in the Statement of Applicability report. Mark as applicable in the same menu reverses the decision. A category or chapter takes the decision for every control below it, so a whole section of a standard can be excluded in one go, and marking it applicable again restores them all.

The switch appears once the control’s framework is adopted, because the decision is recorded against your adoption of it, and works for centralized controls as well as your own.

Tasks

Each control's detail view has a Tasks tab listing the work attached to it — the implementation tasks that are seeded automatically when you adopt the framework, plus any you add yourself. Use Add task to capture follow-up work; it is attached to the control for you, so you never have to re-select it. These tasks feed the Roadmap and appear in the central Tasks worklist alongside everything else.


Comments

Every control's detail view has a Comments tab for discussing it in place, so the reasoning behind a decision stays attached to the record instead of living in a chat thread nobody can find later.

Write a comment with light formatting (bold, italic, underline, lists), reply to any comment (replies cannot be nested further), and edit or delete your own. Deleting a comment that has replies leaves a placeholder so the conversation still reads in order.

Type @ to mention a colleague. They are notified in the app and by email, and can adjust how often they hear about comments under Account → Notifications.

How is this guide?

On this page