Eigene Compliance-Frameworks: bauen Sie Ihre eigenen Controls

Die Grundlagen

Ein Framework, das Sie von Anfang bis Ende steuern.

Eigene Frameworks verhalten sich wie die offiziellen Standards, die devguard pflegt: Controls, Abdeckung, Nachweise und Berichte funktionieren gleich. Der Unterschied ist, dass Sie entscheiden, was die Controls sind.

Ihre Controls, Ihre Struktur

Erstellen Sie jedes Control mit einem Namen, einer Kennung wie 5.7 oder NC-1, einer Beschreibung und einem Typ. Eigene Frameworks sind vollständig bearbeitbar, anders als die offiziellen Standards, die devguard für Sie pflegt.

Sechs Control-Typen

Gruppe, Kategorie, Kapitel, Klausel, Control oder Ergänzung. Bilden Sie einen Standard so ab, wie er tatsächlich geschrieben ist, vom breiten Kapitel bis zum einzelnen Control.

Die Abdeckung funktioniert genauso

Ordnen Sie ein Control den Policies, Risiken und Assets zu, die es erfüllen, legen Sie fest, wie weit jedes davon es abdeckt, und die Abdeckung summiert sich automatisch von unbekannt bis vollständig, genau wie bei einem gepflegten Standard.

Verpflichtend, wo es zählt

Markieren Sie die Controls, die für Ihr Framework nicht verhandelbar sind, damit eine Lücke in dem Moment sichtbar wird, in dem sie entsteht, und nicht erst in der Woche vor einem Audit.

So funktioniert es

Von der Anforderung zur laufenden Abdeckung, in vier Schritten.

Derselbe Weg wie bei jedem Standard in devguard, mit einem zusätzlichen Schritt zu Beginn: Sie definieren die Controls, bevor Sie sie zuordnen.

01

Framework erstellen und Ihre Controls hinzufügen

Starten Sie ein eigenes Framework und fügen Sie ihm Controls nacheinander hinzu. Jedes Control erhält einen aussagekräftigen Namen, eine eindeutige Kennung (eine strukturierte wie 5.1 oder AC-12 hält Ihre Berichte sauber) und, wo es wichtig ist, eine kurze Beschreibung dessen, was es verlangt.

Markieren Sie die Controls, die für dieses Framework verpflichtend sind. Diese eine Markierung macht aus einer offenen Lücke, die leicht zu übersehen ist, etwas, das devguard für Sie sichtbar macht.

02

Geben Sie jedem Control einen Typ

Typisieren Sie jedes Control, damit sein Platz im Framework eindeutig ist: eine breite Gruppe oder Kategorie, ein Ziel, eine Anforderung, ein Control oder eine einzelne Massnahme. Typen erlauben es Ihnen, eine Anforderung so abzubilden, wie sie tatsächlich geschrieben ist, statt alles in eine undifferenzierte Liste zu pressen.

Verdoppeln Sie kein offizielles Control

Wenn eine Anforderung bereits von einem Standard abgedeckt ist, den devguard ausliefert, übernehmen Sie diesen Standard und ordnen Sie sich seinem Control zu, statt es in Ihr eigenes Framework zu kopieren. Reservieren Sie eigene Frameworks für die Anforderungen, die kein veröffentlichter Standard abdeckt. Das hält Ihre Abdeckung ehrlich und Ihre Berichte frei davon, dasselbe Control doppelt zu zählen.

03

Controls Policies, Risiken und Assets zuordnen

Verbinden Sie jedes Control mit den Policies, Risiken und Assets, die es erfüllen, denselben Bausteinen, auf die jedes Framework in devguard zurückgreift. Weil Ihre eigenen Controls diese gemeinsamen Nachweise wiederverwenden, pflegen Sie für sie keinen separaten Satz an Belegen.

04

Abdeckung verfolgen und darüber berichten

Während Sie zuordnen, wird die Abdeckung für Sie berechnet und bewegt sich von unbekannt über teilweise bis vollständig. Ihr eigenes Framework liegt dann in derselben Abdeckungsansicht und denselben Berichten wie jeder offizielle Standard, den Sie betreiben, und wird gemeinsam mit ihnen geprüft und exportiert, nicht in einer Tabelle abseits.

In der Praxis

Drei Dinge, für die Teams eigene Frameworks bauen.

Die Anforderungen, die nie aus einem veröffentlichten Standard kamen, aber trotzdem Controls, Nachweise und jemanden brauchen, der die Abdeckung zeigen kann.

Kundenspezifische Verpflichtungen

Eine Vertragsklausel, die besagt, dass Kundendaten im Ruhezustand mit AES-256 verschlüsselt sein müssen, wird zu einem verfolgten Control mit eigenem Nachweis, nicht zu einer Zeile, die in einem E-Mail-Verlauf untergeht.

Interne Richtlinien

Ein internes Ziel, etwa die Einführung von Zero Trust, erhält ein Control-Set, an dem Sie echten Fortschritt zeigen können, lange bevor jemand von aussen danach fragt.

Lokale Vorschriften

Eine länderspezifische Regel, die devguard noch nicht als Framework ausliefert, lebt trotzdem im selben Workspace, zugeordnet zu denselben Policies und Nachweisen wie alles andere.

Ein Workspace, offiziell und eigen nebeneinander.

Ihre eigenen Controls liegen in derselben Control-Liste, Abdeckungsansicht und denselben Berichten wie ISO 27001, SOC 2 und jeder Standard, den Sie bereits betreiben, zugeordnet zu denselben Policies, Risiken und Assets.

Den vollständigen Funktionsvergleich ansehen

Haben Sie eine Anforderung, die in keinen Standard passt?

Sagen Sie uns, womit Sie konform sein müssen, und wir gehen durch, wie Sie es als eigenes Framework abbilden: die Controls, die Typen und wie es sich den Nachweisen zuordnet, die Sie bereits führen. Keine Präsentation, ausser Sie wollen eine.

Gespräch buchen

FAQ zu eigenen Frameworks

Eigene Frameworks, klar beantwortet.

Was ist ein eigenes Framework in devguard?

Ein Framework, das Sie selbst bauen, mit Controls, die Sie definieren. Offizielle Frameworks kommen mit Controls, die für Sie gepflegt und gesperrt sind; ein eigenes Framework und seine Controls sind vollständig bearbeitbar, sodass Sie einen Kundenvertrag, eine interne Richtlinie oder eine Vorschrift abbilden können, die devguard noch nicht ausliefert.

Wie ist ein eigenes Control aufgebaut?

Jedes Control hat einen Namen, eine Kennung wie 5.1 oder AC-12, eine optionale Beschreibung und einen Typ: Gruppe, Kategorie, Kapitel, Klausel, Control oder Ergänzung. Sie können es zudem als verpflichtend markieren, damit eine offene Lücke darauf gemeldet statt stillschweigend hingenommen wird.

Wie wird die Abdeckung für meine eigenen Controls berechnet?

Genauso wie für offizielle Frameworks. Ordnen Sie jedes Control den Policies, Risiken und Assets zu, die es erfüllen, legen Sie fest, wie weit jedes davon es abdeckt, und devguard summiert das automatisch von unbekannt über teilweise bis vollständig. Es gibt kein separates Bewertungssystem zu pflegen.

Kann ich offizielle Frameworks bearbeiten, statt eigene zu bauen?

Nein. Die Controls in offiziellen Frameworks werden als Teil des Standards gepflegt und können nicht geändert werden. Wenn ein veröffentlichter Standard eine Anforderung bereits abdeckt, übernehmen Sie ihn und ordnen Sie sich ihm zu, statt seine Controls in ein eigenes Framework zu kopieren. Bauen Sie ein eigenes Framework für die Anforderungen, die kein veröffentlichter Standard abdeckt.

Liegen eigene Frameworks neben den offiziellen?

Ja. Ein eigenes Framework erscheint in derselben Control-Liste, derselben Abdeckungsansicht und denselben Berichten wie ISO 27001, SOC 2 oder jeder Standard, den Sie bereits betreiben, und verwendet dieselben Policies, Risiken und Assets wieder, sodass Sie dafür keinen separaten Ordner pflegen.

Bringen Sie die Anforderungen, die kein Standard abdeckt.

Bauen Sie Ihr eigenes Framework, ordnen Sie es den Nachweisen zu, die Sie bereits führen, und halten Sie es neben jedem offiziellen Standard, den Sie betreiben, auditbereit.