In order to control access to a piece of data, it needs to be associated with a specific permission. Association of data and permissions must be configured by the projects to suite business requirements. In this context "access to a piece of data" means:
- access to search for an entity by a specific data attribute
- access to view a specific data attribute of an entity or a service instance (via View entity, Entity extract, Filing, etc.)
- access to edit a specific data attribute of an entity or a service instance (via a maintain entity service)
- access to view a specific filing (via View entity → Filings tab → sub-tabs Completed / All)
During project design phase, consultants capture requirements about the privacy of each attribute of an entity. This can be recorded in a deliverable called Data elements specification. Requirements about the visibility of each filing and service instance are also captured during the design phase and can be documented in the configuration settings section of every business service. Access to populate or edit values of a specific data attribute can also be restricted by permissions and is documented in the specification of each business service, it can be the same access level that is used for viewing of the data or can be completely different.
Privacy levels
Verne uses so called privacy levels for convenience of managing common associations between data and permissions. For example, in the standard product offering we manage privacy of data attributes and filings using the three common privacy levels: public, private and internal (see section ‘Standard privacy levels’ below).
Under the hood each privacy level is mapped to a corresponding permission for each of the registry template or more specifically for each of the entity type.
A data attribute can be associated with its own permission, bypassing privacy levels, this is usually required in cases where access rules are not common, for example when only a user who holds a specific entity relationship can see or edit a specific piece of data. Visibility of the filings can only use privacy levels and must not assign a permission directly (see section ‘Privacy of filings’ below).
Projects will need to define their own permissions for each of the standard privacy levels. Projects can also add their own custom privacy levels (see section ‘Custom privacy levels’ below).
Verne in fact does not use privacy level when deciding if a user can access a specific data attribute, instead it uses the associated permissions directly. This is enabled via so called privacy instructions that are there to configure and execute data attribute visibility rules – see section ‘Privacy instructions’ in Lesson 12: Relationships & privacy.
Permissions to update data
Privacy levels defined for a project can also be used to enable requirements whereby a piece of data can only be updated by a user with specific permissions. For example, in a business service that allows to update entity details ‘Filed A’ can only be made available to the users who have public privacy level permissions, whereas ‘Field B’ – for users with internal privacy level permissions.
Also specific permissions can be used to restrict the access bypassing privacy levels. An example could be the introduction of a permission to lodge a specific document type via Lodge General Document business service, only the users who inherit such permission can have access to select this document type when using the service. Once service is approved, all users can view the document. This also illustrates the case where permission to update data differs from permission to view.
Privacy of filings
During project design phase, consultants capture requirements about the visibility of filings generated by various business services and about the visibility of the business service instances themselves. When filing is generated by an activated business service instance, its default visibility rule is applied. Default visibility rule must be captured in the business service settings by assigning one of the filing visibility levels configured for the project – see setting ‘S02.3 privacy of filing’ in Business Service Configuration. Later the privacy level of a specific filing can be corrected by an internal user via Correct Transaction feature (see Capability D in Correct the Register Capabilities). In this case filing privacy levels stated below are selected by a user from the drop down and are stored against the filings.
Visibility of service instances via filings tab is also determined by the privacy level assigned to each business service at design time in setting ‘S01.4 Privacy of service instance’ in Business Service Configuration. When service instance is initiated, the visibility level is stored against it. It cannot be corrected/changed later on.
When displaying filings and business service instances on the entity Filings tab Verne translates the privacy levels into actual permissions to determine if a user is able to view those filings/service instance.
Standard privacy levels
The following privacy levels are defined in the Verne standard product offering. They are used by all Verne implementations, as they represent the bare bones of data privacy management.
| Privacy level | Description |
|---|---|
| Public | Public data is usually visible to all users: Guest user, External logged in user, Internal user. To achieve this the associated permissions are usually added into the following permission pools: – PP01 Guest user – so that any guest/casual user can access public services and data without being authenticated (logged on). – PP02 External registered user – so that authenticated (logged on) user can access public data – PP04 Internal user – so that a permission can be granted to all internal permission groups For example, entity names are public, therefore casual users can conduct a search by name and see names in search results. Example of permissions associated with level are: COP001 Access public entity data of a company, RNP002 Access public entity data of a name reservation, PRP001 Access public entity data of a professional |
| Private | Private data is usually visible to External logged in user with established relationship over the entity and to all internal user. To achieve this the associated permissions are usually added into the following permission pools: – Relationship type permission pools (PP10+) – so that user with correct entity relationship can access non-public entity data for their entity. – PP04 Internal user – so that a permission can be granted to all internal permission groups For example, entity email address is classed as private data, therefore only internal users and users with director or agent relationship with the entity can view it. Example of permissions associated with level are: COP030 Access private entity data of a company, RNP031 Access private entity data for a company name reservation, PRP030 Access private entity data of a professional |
| Internal | Internal data is usually visible to all internal users. To achieve this the associated permissions are usually added into the following permission pools: – PP04 Internal user – so that a permission can be granted to all internal permission groups For example, the date when filing was submitted but not yet approved is classed as internal only, therefore only internal users can access it. Example of permissions associated with level are: COP060 Access internal entity data of a company, COP061 Access internal entity data of a company name reservation, PRP060 Access internal entity data for professionals |
Custom privacy levels
Custom levels and association of data with a specific permission bypassing privacy levels is typically required to allow for the following scenarios:
- data is available to external users who satisfy a specific condition, that is not common to all external users (e.g. they must have a specific type of entity relationship, they must belong to a specific organisation)
- data is available to a sub-set of internal users
Projects can configure their own custom privacy levels to suite their requirements. Example of custom levels include:
Authenticated / Registered user – a user must be logged in order to access a piece of data
Internal sensitive – this level can be associated with one specific piece of data or a collection of data fields, that require extra level of security clearance and/or access auditing. This helps selectively grant access to sensitive data to internal users. For example, if access to view person’s date of birth or security number needs to be granted selectively to internal users, then there must be a permission created for this e.g. "Access person security number and date of birth" and data elements mapped to this permission.
Agency access – this level can be associated with data that is only visible to users representing selected internal or external institutions. Internal institutions will be represented in Verne as internal permission groups, therefore permissions can be added/removed from the group to achieve required access. External institutions will be represented as external organisations – TBC whether specific external otgs can be granted specific permissions that other orgs do not have.
Several levels of private or internal data – in some cases private data can be divided into various levels. For example, if agents can’t see personal details of a director, such as security number or date of birth, then there must be at least two levels of private data "Private data – agents" for agents and "Private data – owners" for directors and other roles that are treated as ‘owners’.
My own data – this level can be associated with pieces of data that a user can see only if this data is about them. For example, a user profile ‘John’ has active access associated with a director relationship ‘John Smith’ of ‘ABC Company Ltd.’. This gives a user who logs in as ‘John’ access to see John Smith’s date of birth, however they won’t be able to see date of birth of another director Anne Roberts.
Note, achieving some of the custom privacy levels might require product support, as might not be fully achieved via configuration.
Each new level requires a new permission to be introduced for each protected piece of data or group of data elements. Projects must also place such permissions in the correct permission pools and permission groups to ensure the right users inherit them.
Privacy pyramid
The following diagram is an example of privacy levels that could be implemented by the project. There are two custom levels added on top of the three standard levels: Registered user and Audited.
