-
Intro
-
General Guidance
-
Tasks
-
Compliance
-
Controls
-
Meta Model
-
Administration
General Guidance
Blueprints
Role-Specific Access
In general, blueprints are available to all users.
The following factors decide about the availablity of blueprints to specific tenants:
- Blueprints need to be enabled on tenant basis (by a tenant admin).
- Users of the tenant require access to the respective vucavoid feature (e. g. access to controls management if control blueprints should be imported).
- Every blueprint that should be accessible needs to either be vucavoid-defined (see below) or made specifically accessible for the tenant.
- Once a blueprint has been imported, the new entity is disconnected from the availability of a blueprint.
Overview & Concept
Compliance management can be a daunting task that is connected to many tedious routine tasks. Especially when beginning to set up compliance management or extending it for new domains, a fresh start is a tough task.
Blueprints are like organization-agnostic templates for specific entity-types in vucavoid. It is important to note, that blueprint and tenant entity types cannot be mixed - they coexist in different worlds.
They are designed to be imported into a vucavoid tenant at any time, providing the tenant's organization with a head start for developing new entities of the specific entity types.
Once a blueprint is imported, into a tenant, it becomes a tenant-specific entity (e. g. a control) - which only exists in the context of the specific tenant. Blueprints that are imported to multiple tenants have no connection to one another.
For user-defined (personal) blueprints, the accessibility of such can be restricted to specific tenants (see below), which does not influence the general rule outlined above. Even if blueprints are defined to only be visible for specific tenants, the imported entities from such a blueprint is only accessible for the importing tenant. The only information remaining is that the entity had been imported from a blueprint, being statistical information that can be viewed by the importing tenant. The author of the blueprint can only see that is has been imported but does not have further details in access.
To put it into other words: Blueprint are shells on a different level, transforming into a tenant-specific entity once imported, loosing its ties to the blueprint.
Relevant entity types
Controls Management
- Controls
- Control Ojectives Requirement Management
- Requirements
- References Structures
- Domains
- Standards
- Categories
- Assurances
Types of blueprints
In vucavoid, there are two types of blueprints.
Blueprints can either be defined by vucavoid or by single user accounts.
| Author | Purpose | Visibility |
|---|---|---|
| vucavoid | General and broad approach to provide a head-start to organizations, especially small and medium sized entities (SMEs), in building up or extending their compliance management. | Per default visible for all tenants. |
| user | As set by the author (user), major use cases are either set for | Can be individually shared by the author and are private per default. Visibility can be controlled by two factors: 1. Author needs to publish them (in draft per default). 2. Tenants needs to be specifically selected to have access. Note, this can also lead to travelling blueprints between all specifically selected tenants but does never lead to tenant-specific entities (imported blueprints) travel between tenants. |
Note: Visibility of blueprints is subject to tenant-specific blueprint settings (if blueprints are not allowed, neither vucavoid- nor user-defined blueprints can be accessed from that tenant).
Activation of blueprints per tenant
Before blueprints can be used by any user within a tenant, the tenant admin needs to activate them in Tenant Settings.
To do so, a tenant admin needs to visit Tenant Settings of the specific tenant (be mindful if part of multiple tenants). On this page, the admin can activate blueprints on the level of available blueprint entity types.
Even though the activation of specific blueprint entity types does not influence others, it is recommended to activate blueprint entity types following a potential import logic.
Example:When activating blueprint controls but not blueprint control objectives, this might lead to an inconsistent import basis since most blueprint contols have pre-defined links to blueprint control objectives. The same inconsistency might be given when importing blueprint sets (see box below).
Every activation of a specific blueprint entity type has to be confirmed via a modal request - the same appplies to deactivation.
Please note: Even if an user has access to blueprints in a different tenant, the user cannot access blueprints in a tenant that did not activate blueprints for use.
Import of blueprints
Regardless of type of blueprints (vucavoid- or user-defined), once a blueprint is available to a tenant, it can be imported to the tenant.
Blueprints can be imported from the tenant's overview for the entity type that an user wants to import a blueprint for.
Example: An user wants to import a blueprint control to become an actual control in the user's tenant, the user finds the option to do so in the overview of the tenant's controls.
Once the user clicked the button, a slide-over will open showing a list of all (to the tenant) available blueprints of the respective entity type.
To simplify the user experience, the view for blueprints is kept the same across blueprint entity types.
Columns
Per default, there are six columns displayed in the overview of importable blueprints.
- Type of blueprint: Cog symbol (⚙️) represents a vucavoid-defined blueprint. A user symbol (👤) represents an user-defined blueprint. Hovering the symbol reveals more information on its origin.
- Status: In the import view, only published blueprints are shown. When defining personal blueprints, drafts are also shown.
- Title: Title of the blueprint.
- Affected structures: Bullet list of all affected domains, categories, standards and assurances.
- Import history: Cloud symbol (☁️) tells the blueprint has not yet been imported to this tenant. A cloud symbol with a downwrds arrow (☁️⬇️) represents
- Expansion: Clicking the chevron symbol expands further informtion on the blueprint entity of the specific row.
Please note: Even if collapsed, users can still search all collapsed content for better navigation.
To proceed with the import, users can select one, multiple or all blueprint entities that are available to the active tenant. To select all blueprint entities at once, the user can either click the checkbox left to the first column above the table or use the select all button on the top right of the table.
Please note, that clicking the checkbox on the top left of the table only selects the visible blueprints entities - with visibility depending on the pagination option for the respective table.
Once all blueprint entities, supposed to be imported, are selected, the user can click "Next" on the right side below the table to proceed.
Import of dependencies
During the import, the user will be asked to either
- confirm the import of all data releated to the blueprint entity or
- overwrite the dependencies with tenant-specific data.
The decision on this is primarily depending on the tenant's need for the specific blueprint.
Once confirmed, the blueprints will be imported to the tenant.
Please note:
- Some entities will not become productive if specific information is not amended to it
- If relevant to the operational compliance management of the tenant, imported entities will not be in an active status. Controls will be imported in draft mode to be subject to further review before being activated.
Sets: SOC-2 or ISO out-of-the-box
Sets are an attribute for blueprints to show affiliation with other blueprint entities. Sets can be applied across all blueprint entity types, creating associated chains of blueprint entities.
For personal (user-defined) blueprints, the only sets available are the ones as defined by the user. Sets cannot be explicitly shared across different users.
Example
A law, a standard or a specific contract needs to be fulfilled by an organization. To plan for compliance, an organization would start with understanding the requirements, mapping it to its existing compliance management setup and plan accordingly for an implementation of controls.
- With blueprint sets, an user can create a blueprint requirement, link the specific reference to it (e. g. a law) and consequently create relevant blueprint control objectives with blueprint controls attached to it.
- To go further, the user could even link this to matching blueprints of domains, standards, categories and even assurances.
- With blueprint assurances, users could even create a full ISO 27001 or SOC-2 set, ready for import to a tenant.
Now, this example can be expanded further by having multiple tenants that need to comply with the requirements. By sharing blueprints as a set across different tenants, multiple organizations (tenants) can easily use a** head-start to achieve compliance**.
Major uses cases for the usage of blueprint sets:
- As a consultant preparing a set (or multiple sets) of blueprints can provide every client with a kickstart to the implementation of specific compliance requirements.
- With a group of companies (concern), the group office for infosec (or other domains) could easily roll-out the same set of requirements and/or controls to different tenants within the group.
Personal (user-defined) blueprints
Next to the vucavoid-defined blueprints, which users and tenants cannot influence, users can define their own blueprints for all available blueprint entity types. These blueprints are of type "personal blueprints" (or user-defined blueprints). Users can define and manage these regardless if any tenant they belong to has blueprints enabled for import or not.
To access personal blueprints, users can use their user dropdown menu by clicking its avatar and then select "Personal blueprints".
By using the tab naviagtion on top, users can switch between the different blueprint entity types.
Regardless of the activated tab, users can create new blueprint entities by using the green button for a new blueprint in the top right of the screen.
Blueprint entites can be linked to other blueprint entities (e. g. a blueprint control can be linked to a blueprint control objective) but never to active tenant data.
A newly created blueprint entity will not be published but created in draft mode. This cannot be changed to protect unwanted publications of unfinished blueprints (or even sets).
Once created, users can publish a single blueprint or select multiple blueprints to publish them at once. If multiple blueprints are selected, the status of each selected blueprint will be inverted, meaning blueprints in draft status will be published and published blueprints will be put back in draft mode.
Further, even published (user-defined) blueprints need to be be specifically made available to tenants for import. The authoring user can only select tenants that the user is active part of (regardless of role assignments in the tenants).
Users can also define blueprint sets (associated blueprints). To manage user-defined sets, the user can click the "Sets" button at the top right above the blueprints overview. One or multiple sets can be assigned to each blueprint entity. Defining sets can facilitate the provision of blueprints across tenants (e. g. based on specific topics like ISO 27001 related blueprints).