As a SaaS application, Bizzdesign Horizzon uses a shared responsibility model. Some settings and policies are implemented and managed by Bizzdesign, and others by the customers. With regards to data retention, or Personally Identifiable Information (PII), the responsibilities are defined in the following way:

• All information needed to provide access to the application, enable auditability of events within the application, and maintain the service are managed by Bizzdesign.
  
  
• Data and settings within the application are managed by the customers.
  
  
• Bizzdesign is responsible for securing underlying infrastructure hosting such data and maintaining appropriate backups to prevent data loss.

Bizzdesign responsibilities and implementation

The PII retained by Bizzdesign is stored and maintained according to applicable regulations, including GDPR, and is limited to:

• Information needed for contractual purposes (e.g., signed contracts including signatures, billing, and operational contacts, submitted support tickets, et cetera).
  This information is retained according to applicable laws and regulations, typically for the duration of the contract and several years after termination of the contract.
  
  
• Information needed for product maintenance and operational purposes.
  This includes product log files that may contain PII, which are typically retained for less than 30 days unless events are considered security-sensitive, in which case they are typically retained for 12 months.
  
  
• Information about product usage used for product improvements.
  Such data is anonymized/aggregated according to the Bizzdesign privacy policy and not considered PII after such anonymization/aggregation.
  
  
• Account- and security-related information within a customer's application environment.
  This includes the Horizzon audit log, which is, by default, retained for the entire duration of a Bizzdesign subscription. Older data can be removed upon customer request by submitting a ticket to Bizzdesign Support. Information about created user accounts is, similarly, stored for the duration of a Bizzdesign subscription and includes, at a minimum, first name, last name, and e-mail address. This information is retained after the deletion of the individual user account for operational purposes (e.g., showing who created/updated specific information) and cannot be removed.

The related policies and procedures are in scope for the Bizzdesign SOC2 report/audit, the latest copy of which is available upon request.

Customer responsibilities and implementation tips for data retention policies

In general, Bizzdesign Horizzon stores both past/current state and desired future state for Enterprise Architecture; this type of data is usually not subject to data retention requirements. For customers that do store data subject to such requirements, it is important to note that three types of data can be stored and maintained in Bizzdesign Horizzon:

Information stored via commits

Models created in Enterprise Studio are generally stored via commits. Information in commits is retained on Bizzdesign's servers for the entire lifetime of a model package. Both the Enterprise Studio application and the Horizzon web application will only show the current state of the model package and will not show any data that has been removed. It is however possible to restore the state of the model package to a past state, and older information can theoretically also be accessed via alternate paths (e.g., accessing cache files stored on the filesystem by Enterprise Studio).

This means a risk analysis needs to be performed to determine which data subject to data retention requirements can and cannot be stored in this manner; for data that can be stored via commits but is subject to data retention requirements, Enterprise Studio's scripting features can be used to remove certain data after a predetermined time automatically. By default, the creation date and last update date of objects can be viewed and/or accessed via a script, and additional properties can be added to store information, such as the desired retention period. The instructions for automating the execution of Connection models can also be used to automate running such a script at periodic intervals. For highly sensitive data subject to automatic deletion/retention requirements, it is recommended to store this via Horizzon data contribution (see below).

In cases where highly sensitive data was accidentally included, which should not be available through the model package timeline, the recommended resolution is to create a backup of the entire model package, import that backup into a new model package, and then erase the original model package. The backup will only contain the current state of the model package.

Information stored in OpenSearch

By default, OpenSearch indexes reflecting the current state of all model packages are created automatically. These indexes are kept up to date upon each commit; that means any data removed from the model package will also be removed within OpenSearch, and no special measures need to be taken there.

Enterprise Studio also has the ability to create custom indexes containing customer-selected data. These are only updated when the corresponding Connection model is executed, and depending on the settings chosen by the customer, may retain old information. For more information on custom indexes, please refer to Data integration with OpenSearch Dashboards.

For custom indexes, several measures can be used to deal with data retention requirements, including the following:

• Not including data subject to data retention requirements in custom indices.
  
  
• Alternatively, make sure the Connection models are set up to remove data that is no longer present in Enterprise Studio's model packages, and ensure that these models are executed periodically. Either through internal procedures ensuring manual execution or by automating the execution. For instructions about such automation, please refer to Configuring periodic model data exchange.

Data stored outside of commits

For data stored via data contribution mechanisms in Horizzon (e.g., via data contribution or through the Bizzdesign OpenApi, or other similar methods outside of Enterprise Studio commits), only the latest value is stored and accessible, except object names for objects referenced in Enterprise Studio views. The last update date for this type of data is available through the Open API, and additional properties can be added to indicate creation data/retention requirements. The API can then be used to remove such data after a defined time automatically. 

Note that updates of this type of data can be stored in the Horizzon audit log; however, this log file is only available to Horizzon users with System Administrator permissions and/or API clients that have been explicitly granted access permissions for audit events.