Not every requirement comes from a published standard. A client contract, an internal guideline, a country-specific rule devguard doesn't ship yet — define your own controls, give them identifiers and types, mark what's mandatory, and map them to policies, risks and assets exactly like an official framework. One coverage view, one evidence base.
Custom frameworks behave like the official standards devguard maintains — controls, coverage, evidence and reports all work the same. The difference is you decide what the controls are.
Create each control with a name, an identifier like 5.7 or NC-1, a description and a type. Custom frameworks are fully editable — unlike the official standards devguard maintains for you.
Group, category, chapter, clause, control or amendment. Model a standard the way it is actually written, from a broad chapter down to a single control.
Map a control to the policies, risks and assets that satisfy it, set how fully each one covers it, and coverage rolls up from unknown to full automatically, exactly as it does on a maintained standard.
Flag the controls that are non-negotiable for your framework, so a gap on one is visible the moment it opens rather than the week before an audit.
The same path as any standard in devguard, with one extra move at the top: you define the controls before you map them.
Start a custom framework and add controls to it one at a time. Each control gets a descriptive name, a unique identifier (a structured one like 5.1 or AC-12 keeps your reports clean) and, where it matters, a short description of what it asks for.
Mark the controls that are mandatory for this framework. That single flag is what turns an open gap from something easy to overlook into something devguard surfaces for you.
Type each control so its place in the framework is unambiguous: a broad group or category, an objective, a requirement, a control, or a single safeguard. Types let you model a requirement the way it is actually written instead of flattening everything into one undifferentiated list.
If a requirement is already covered by a standard devguard ships, adopt that standard and map to its control rather than copying it into your custom framework. Keep custom frameworks for the requirements no published standard covers — it keeps your coverage honest and your reports free of the same control counted twice.
Connect each control to the policies, risks and assets that satisfy it — the same building blocks every framework in devguard draws on. Because your custom controls reuse that shared evidence, you are not maintaining a separate set of proof for them.
As you map, coverage is calculated for you and moves from unknown to partial to full. Your custom framework then sits in the same coverage view and the same reports as every official standard you run, so it is reviewed and exported alongside them — not in a spreadsheet off to the side.
The requirements that never came from a published standard — but still need controls, evidence and someone able to show coverage.
A contract clause that says client data must be encrypted with AES-256 at rest becomes a tracked control with its own evidence — not a line buried in an email thread.
An internal objective, like rolling out zero trust, gets a control set you can show real progress against, long before anyone outside asks to see it.
A country-specific rule devguard does not yet ship as a framework still lives in the same workspace, mapped to the same policies and evidence as everything else.
Your custom controls live in the same control list, coverage view and reports as ISO 27001, SOC 2 and every standard you already run — mapped to the same policies, risks and assets.
Tell us what you need to comply with and we’ll walk through how to model it as a custom framework — the controls, the types, and how it maps to the evidence you already keep. No deck unless you want one.
A framework you build yourself, with controls you define. Official frameworks ship with their controls maintained for you and locked; a custom framework and its controls are fully editable, so you can model a client contract, an internal guideline or a regulation devguard does not ship yet.
Each control has a name, an identifier such as 5.1 or AC-12, an optional description, and a type — group, category, chapter, clause, control or amendment. You can also mark it mandatory, so an open gap on it is flagged rather than quietly tolerated.
The same way it does for official frameworks. Map each control to the policies, risks and assets that satisfy it, set how fully each one covers it, and devguard rolls those up automatically from unknown through partial to full. There is no separate scoring system to maintain.
No — the controls in official frameworks are maintained as part of the standard and cannot be changed. If a published standard already covers a requirement, adopt it and map to it rather than copying its controls into a custom framework. Build a custom framework for the requirements no published standard covers.
Yes. A custom framework appears in the same control list, the same coverage view and the same reports as ISO 27001, SOC 2 or any standard you already run — and reuses the same policies, risks and assets, so you are not maintaining a separate binder for it.
Build your own framework, map it to the evidence you already maintain, and keep it audit-ready beside every official standard you run.