What is this workspace template for?

This workspace is for documenting the internal and external applications that the sensitive data in your organization passes through. These are then connected to the services, databases, and data that they interact with to help build a complete picture of your IT landscape. In addition to a complete overview of your portfolio, we have included additional fields to capture information to answer GDPR compliance questions like responsibility and storage location.

Each “Application” component consists of “Services” components, “Applications” access “Database” components in the Infrastructure workspace, and owns/duplicates “Data Entity” components in the Master Data workspace.

Component types contained in this template

  • Application/External Application
  • Service/External Service

The Application / External Application components are for documenting the application (systems, tools, IT services etc.) that process personal data. The difference between these components are meant to help guide permissions and to capture the minimum information necessary. External applications should have more information around the agreements, storage locations etc. Often organizations will share access to workspaces to external hosting providers or partners and therefore wish to keep the two portfolios of applications separate. Other than this, there is no reason why you can’t rename the External Application model and create a single repository for all your applications.

The Service / External Service components are for documenting more detailed functionality or services within an application. This may be for example the createCustomer service commonly found in a CRM application. Using this level of detail will help you also better understand how data is used and to what purpose. It is also valuable information to see potential points of optimization, duplicate or redundant functionality and cost saving opportunities.

Reference types contained in this template

  • Asynchronous
  • Synchronous
  • Fire and Forget
  • Connects to
  • Owns
  • Duplicates
  • Uses
  • Runs on

The Asynchronous, Synchronous, and Fire and Forget references are used to describe the type of integration existing between applications or services. The goal in identifying this is purely operational for information architects, system owners, developers etc. These were left in the GDPR models to provide additional value beyond regulatory documentation and help motivate end users by giving them insights into what matters to them. Some choose to remove these and simply use an “Integration” type reference or connects to.

The Connects to reference is meant to be used between applications to simply give a high level overview of integrations. Typically a supplement to the detailed integration types listed above.

The Owns reference is used to show ownership of data entities (see Master Data). This is helpful in understanding master data management and highlighting duplication of data (for GDPR).

The Duplicates reference type is used when an application copies a Data Entity. This is helpful in understanding master data management and highlighting duplication of data (for GDPR).

The Uses reference type is to identify data entities used by the application but that are not duplicated. This will be helpful in understanding access management to personal data and identifying what security and retention policies applications may be subject to.

The Runs On reference is used to explain the hosting or infrastructure the application hosted on.

Fields contained in this template

  • Lawful basis (list)
  • System Responsible (email)
  • Storage Location (list)
  • DPA in Place? (check box)
  • Link to DPA (URL)

The Lawful Basis field is used to capture the necessary documentation to defend your usage of personal data as referred in article6. This will be found on the Owns, Uses, and Duplicates reference types.

The System Responsible field is an email field that provides you the ability to show accountability for the processing of the data in that application. Another reason for choosing the email field type is the ability to integrate Ardoq for automated and direct notifications for outages and other cases. We have also seen people use slack IDs and the like for immediate notifications via an API integration.

The Storage Location is a simple field to help provide an overview of where you are sending data outside the EU/EEA. Here you have a simple list, but many choose to replace this with a dropdown of all known countries for even better control.

The DPA in Place field is meant to highlight your work in securing the necessary Data Processing Agreements. Check for Yes!

The Link to DPA field is a quality assurance measure to be able to easily check that not only is the agreement is in place but that you can find it in a moment of need.

**Potential fields to add:

– Expiration dates for DPAs. Beneficial for longterm management of DPAs.

– Legal grounds and safeguards in place for external data transfers outside EU/EEA. Refer to Chapter 5 in the GDPR

How to…

List all of you sofware applications/IT systems:

  1. For this purpose, use the component type “Application” or “External Application”.
  2. If necessary, map the technical services, methods or functionality within each application. For this purpose, use the component type “Service” or “External Service”.
  3. For each application, document the person responsible in the field “Responsible (email)”.

Map which data entities are accessed by each application and how:

  1. Use the reference types “Owns”, “Duplicates” and “Modifies” to distinguish between the three, taking care to be consistent when selecting the source- and the target component. The source component should always be of the type “Application” or “External Application”. The target component should always be of the type “Data Entity”, which should be documented in its own master data workspace.
  2. For each such reference, document the lawful basis for the handling of the data in the field “Lawful Basis”.

Map your integrations landscape:

Document how the applications are integrated by creating references of the types “Asynchronous”, “Synchronous”, “Fire and forget” and “Connects to”.

Map the dependencies between your application landscape and your infrastructure:

Document what parts of the infrastructure each application is dependent on by creating references of the type “Runs on”. Take care to be consistent when selecting the source- and the target component. The source component should always be of the type “Application” or “External Application”. The target component should always be a component in the infrastructure workspace.

Did this answer your question?