GDPR - Functionality

Background

The General Data Protection Regulation (GDPR) contains rules on how personal data may be processed. It took effect on May 25, 2018, replacing the Swedish Personal Data Act (PuL). At BRP Systems, we do our utmost to provide our customers with tools that help the data controller fulfill obligations under the regulation.

Terminology

• Data Subject: The individual registered in the system, typically customers or employees.

• System: The BRP Systems business system, excluding integration points such as hardware, customer customizations, and integrations with third parties.

• System Provider: BRP Systems AB.

• Customer: The legal entity purchasing access to the System as a service from the System Provider.

• Personal Data: Any information relating to an identified or identifiable natural person.

• Processing: An operation or set of operations performed on personal data.

• Pseudonymization: Processing personal data in such a way that it can no longer be attributed to a specific data subject without the use of additional information.

• Data Controller: The legal entity registering individuals. In this case, the company running the facility.

• User: A person who uses the System on behalf of the Data Controller (typically an employee).

About This Document

This document is intended for internal use by the System Provider and for the System Provider’s customers to:

1. Describe the division of responsibilities between the Customer and the System Provider.

2. Outline the System Provider’s planned development of the System to help customers comply with GDPR (note that the measures in this document are not final and may change).

3. Present potential future development offered as add-ons by the System Provider, which are not included in the System’s basic functionality.

4. Provide tips for customers on configurations and procedures related to the System to meet GDPR requirements.

Responsibilities

Anyone who processes personal data—e.g., by collecting or storing it—is either a Data Controller or a Data Processor, and GDPR imposes different requirements and obligations depending on the category.

• The Data Controller is responsible for ensuring that any personal data processing, whether carried out by the controller or on its behalf, complies with GDPR’s provisions.

• The Data Processor is responsible for providing sufficient guarantees that the processing meets GDPR requirements and ensures the rights of the data subject are protected.

With respect to processing personal data within the System, our customers are generally considered Data Controllers, and the System Provider (BRP) is a Data Processor.

We encourage our customers, together with legal counsel, to consider and assess how GDPR requirements specifically affect you. This information brochure is only meant to illustrate how the System Provider is working on preparations for GDPR and should not be taken as a complete guide or specific legal advice on the measures required to comply with GDPR.

Exports and Integrations

If you export information from BRP to an external system, for example via API integrations or export templates, you must ensure that information in the external system is handled in compliance with GDPR.

Development of GDPR Functionality

Some enhancements to the product will become part of the basic functionality; others will be available as add-ons (as part of “GDPR Tools”). Pricing will be announced at a later date.

Subsequent pages in this document describe the System Provider’s changes to System functionality. The information, planned development, and procedures are grouped under the areas of GDPR to which they primarily relate.

Sections labeled “Procedures” are aimed at the Data Controller (system administrator or staff) with suggestions for configuring the new functionality and using it in day-to-day operations.

Changes are available from version 2018.1002. The majority of our customers were updated in April 2018.

Settings

Settings related to these changes are collected under Configuration > Settings > Category > GDPR.

Some settings are only available if the “GDPR Tools” add-on has been purchased and activated in your installation.

Agreements and Consent (Basic Functionality)

Information

All purchases of services and other products can be considered agreements. To deliver the service, you need the individual’s basic personal data in order to:

• Communicate with the Data Subject (name, address, email address, phone number).

• Avoid duplicates during registration (personal identity number).

• Manage direct debit (personal identity number).

• Determine age for, e.g., swimming lessons or youth prices (personal identity number, date of birth).

• Offer a safe training environment (entry control and visitor lists in case of incidents).

• Present training statistics (visits and sessions).

• Handle inquiries, returns, and refunds (bookings and purchases).

Agreement Terms on Registration

• If the system setting "Require acceptance of agreement terms upon manual registration of the customer" is enabled, a question is asked during manual registration (in Back Office or Customer Routines) whether the person being registered has accepted the agreement terms before their data is saved. The user and time are logged.

• After the terms are accepted, a dialog is shown for selecting consent options.

• You can create a message template "Agreement Terms on Registration" under Settings > Message Templates.

• If the “Agreement Terms on Registration” message template exists, new customers must accept these terms when registering through Internet Booking. The acceptance time is saved.

• If the message template exists, existing customers must also accept the terms when booking group activities or signing a subscription in Internet Booking. The acceptance time is saved.

• When registering or updating a person via API, you can send the timestamp of when the person accepted the registration terms, and it is stored in BRP.

• The time a person accepted the agreement terms at registration can be viewed and changed on the person card’s Marketing tab.

• The acceptance time can be used as a criterion in Advanced Search.

• Users with the right “Persons - Mass Edit Data” can highlight one or more people in the Person List, right-click, and mass edit the acceptance time for the registration agreement terms.

• The system setting "Require acceptance of agreement terms for registration if not done after..." forces a customer to accept the agreement terms again before booking online if the terms have changed since they last accepted.

• You can create a link #/reflink/mypages?subpage=profile that leads directly to “My Pages” in Internet Booking. By emailing this link, customers can log in and accept the terms at your request.

• A new message template "Personal Data Policy" is shown on “My Pages” in Internet Booking if it exists.

If setting “askForTermsOnManualRegistration” is enabled, the following dialog appears when creating a person in BRP:

Open

If setting “showConsentsDialogWhenCreatingPerson” is enabled, the next step shows the consent dialog:

Open

Consent to Mass Mailing

• Three new system settings control default values for consent to mass mailing via letter, email, and SMS. These replace the old setting "Allow mass mailing by default" and inherit its value.

• You can create message templates for Consent to Mass Mailing by letter, email, or SMS.

• During manual registration in Back Office or simplified Customer Routines, the default values for consent to mass mailing are used.

• During registration in Internet Booking, the newly registered individual can choose to give consent to mass mailing, provided these message templates exist.

• If the system setting “Show unsubscribe link in email” is enabled, individuals can withdraw consent via a link at the bottom of each mass email (sent from the person list) that originates from the System.

• If showUnregisterLinkInSMS is enabled, a link is added in SMS messages sent from the person list, e.g., “To unregister: http://...”. This often results in two SMS messages concatenated into one on the phone.

• It is possible via Internet Booking (Generation 2) to change consent to mass mailing.

Procedures

1. Formulate a clear agreement explaining what information is stored, why, and how it is used. Place it in the “Agreement Terms on Registration” message template.

2. Inform the customer that providing a photo is voluntary (if applicable) and that the photo may be used for spot checks and displayed on screens when entering.

3. Inform about integrations and automatic exports that lead to customer data being sent to third parties, and why these are necessary to deliver the service.

4. If you still use Internet Booking Generation 1, carefully assess whether it meets GDPR requirements since it is no longer under active development. Consider disabling user registration in Generation 1.

5. Configure default values for consent to mass mailing (letter, email, SMS). You likely want to set them to “No.”

6. Create message templates for mass mailing consent by letter, email, and SMS.

7. Create a message template for the “Personal Data Policy.”

Limiting the Storage of Personal Data (Basic Functionality)

In order for anonymization to be possible, personal data should, as far as possible, be tied to the person object itself. That way, anonymization can be done thoroughly.

Avoid writing personal data in message fields for bookings, orders, or other fields outside the person card.

Restrict Access to Personal Data (Basic Functionality)

To prevent personal data from being unnecessarily visible to users who do not need it, new rights are introduced along with the ability to limit the number of search results and actively toggle the display of data—combined with logging.

Limit the Number of Matches in Person Search

• System Setting “Max number of matches when searching for persons” sets a maximum number of search results. Setting it to 0 means no limit.

• A Right “Persons - No limitations in person search results” allows certain users to see unlimited results, regardless of the system setting.

Restrict Access to Personal Data as Needed

• System Setting “Restrict access to personal data” hides address, phone number, email address, personal identity number, date of birth, photo, and payer number on the person card in Back Office, simplified Customer Routines, and web-based service bookings. The user can actively choose to display them, and that access is logged with the user name and time.

• A Right “Persons - Unlimited access to personal data” lets the user see all personal data without any logging, regardless of the system setting above.

• When looking up a person in Internet Booking, most retrieved data is masked. If the registration is completed, the data will be visible under “My Pages.”

Procedures

1. Configure the maximum number of person-search results.

2. Configure the Person List so only the columns absolutely necessary to find the right individual are shown—perhaps just first and last name.

3. Use caution granting rights that enable extensive searching or access to personal data.

4. Use caution granting rights that allow exporting person lists.

5. Regulate, via agreement, which data API integrators and recipients of automated exports may handle.

6. Review agreements with your customer if you export personal data to third parties (integrators, external email systems, etc.).

Manual Anonymization (Basic Functionality)

Anonymizing means data stored in the System can no longer be associated with a real person. It is up to the Data Controller to decide when a registered individual should be considered inactive and possibly anonymized.

• Right “Persons - Mark for anonymization” determines which users can mark a person for anonymization.

• You can mark one or more persons for anonymization using the “Delete” button in the person list, assuming there are no active subscriptions, unpaid debit balances, account debts, bookings, etc.

• A System Setting “Number of months to store inactive personal data” states how long, based on employment, subscriptions, bookings, etc., a person is considered active.

• Another System Setting “Number of months before new persons can be considered inactive” indicates how many months after they are created the person is considered active, even if they have made no bookings or purchases.

• Under Back Office > Persons > Tools > “List Inactive Persons,” you can find inactive persons and mark them for anonymization.

• Right “Persons - Complete anonymization” determines which users can finalize anonymization.

• You can list marked persons via Advanced Search, right-click, and choose “Complete anonymization” or “Unmark anonymization.” Once anonymized, a person’s first name becomes “Anonymous.” All personal data is removed, but the person object, bookings, visits, etc., remain.

• Contracts are detached during anonymization (contracts contain personal data).

• Debits are detached (because debits contain personal data).

• Autogiro authorizations in Sweden are detached and deregistered upon anonymization.

• Avtalegiro mandates in Norway are detached and inactivated.

• Direct Debit in Poland is detached and inactivated.

• E-invoice authorizations in Finland are detached and inactivated.

• An anonymized person object does not appear in the person list.

Conditions for Anonymization

A person cannot be marked for anonymization if they:

• Are an employee.

• Have a debt.

• Have uncompleted bookings.

• Have undebited bookings.

• Are a participant in an ongoing or future event.

• Have an active subscription (as payer or user).

• Have a valid value card.

• Have a role as an API integrator.

Effects of Finalizing Anonymization

When a person is fully anonymized, the following actions occur:

• Autogiro authorizations are cleared.

• E-consent is cleared.

• RCP mandates are cleared.

• E-invoice authorizations are cleared.

• Custom fields are cleared.

• The person is removed from the email recipient list.

• Change history is cleared.

• “Direct Debit Poland” is cleared.

• Digital signature is cleared.

• Autogiro log is cleared.

• All documents linked to the person are removed, except for contracts where only the person link is removed.

• The link to the person on debits is removed (but the name & address on the debit remain).

• The person link on organizational pre-orders is removed.

• The person link on value cards is removed.

• The person link on participants is removed.

• The link between this person and any other persons is removed.

• The person link on resources is removed.

• The person link on previous purchases is removed.

• Birthdate is set to January 1 to prevent identification (the year remains for statistics).

• The person’s email is removed from BRP’s MailChimp list.

• The person’s email is removed from BRP’s Carma Compost list.

• The following fields are cleared:

  • Customer number

  • Name

  • Address

  • Email

  • All phone numbers

  • Organization link

  • Auth token

  • Card number

  • Photo

Procedures

1. Decide which users will get the new rights.

2. Establish a procedure for handling customers who cancel or let their subscription expire.

3. Because it’s not unusual for customers to return or regret their cancellation, you may mark them for anonymization, then wait a few weeks before finalizing.

Automated Anonymization (GDPR Tools Add-On)

A set of tools that automate anonymization through rules and scheduled activities.

Before you activate automatic marking and final anonymization, thoroughly test the selection by using “List Inactive Persons.”

Functionality

(Video: “Automated Anonymization” – Subtitles in Swedish/Norwegian can be activated.)

• If the scheduled activity “Mark and complete anonymization of persons” is active, the system can automatically mark inactive persons for anonymization each night based on “Number of months to store inactive personal data.”

• If the system setting “Number of days to wait before anonymizing” is used, the system can automatically finalize anonymization each night for persons who were marked at least x days ago. Leave the setting blank to disable the feature.

• You can mark certain people to exclude from anonymization (e.g., company contact persons with no debits or bookings). GDPR Tools is required to use this.

• With Advanced Search, you can find people excluded from anonymization.

• System Setting “Clear free-text fields upon anonymization” also deletes any free-text fields (notes, messages, etc.), as they may contain personal data. This includes the customer journal.

When “Clear free-text fields upon anonymization” is enabled, the following also happens:

• Internal/external notes & customer messages are cleared.

• Marketing activities are removed.

• Messages and greetings on a value card connected to the person are removed.

• Information fields on the resource are removed if the person was an employee.

• Extra info on waiting lists is removed.

• Internal/external messages on orders and bookings are removed.

• Subscription comments are removed (could be added during deviations).

Procedures

1. Decide whether to clear free-text fields upon anonymization.

2. If final anonymization is not fully automated, create a procedure for who executes the manual step and how often.

3. Even if final anonymization is automated, manually review the list of persons marked for anonymization initially to ensure the selection process suits your operations.

4. Once you’ve found the right settings, you still need to check the list every couple of weeks (not more than 30 days) to ensure it continues to work correctly.

Data Purging

GDPR guidelines mention that anonymization and purging help ensure data is not stored longer than necessary. Personal data can be purged manually. We have chosen to focus initially on anonymization, because purging bookings, purchases, visits, etc. would severely limit:

• Sales statistics

• Service for returns and complaints (the link between the Data Subject and the booking/purchase is needed if they haven’t kept the receipt).

• Visitor statistics (needed to plan staffing throughout the year).

• Access logs (needed for security in case of incidents and troubleshooting if customers report issues).

• Training statistics (displayed to the end customer / Data Subject).

Communication with Previously Registered Persons (GDPR Tools Add-On)

If you determine it’s GDPR-compliant (using a balancing of interests), you can enable a feature that, during anonymization, transfers the person’s email address to an external email system (e.g., MailChimp). This lets you inform customers about your services even though they’re no longer registered in the System.

Functionality

• Setting “Add persons to external mailing list upon anonymization” enables this feature.

• During anonymization, the person’s email is automatically added to a list in external email systems (MailChimp or Carma Compost, if configured), provided “Allow mass emailing via email” is enabled.

• A separate list called “External” is created in MailChimp.

Procedures

If the feature is enabled but you have a reason not to transfer a person’s data to an external email system when they’re being marked for anonymization, disable “Allow mass emailing via email” for that person.

Communication Without Consent (GDPR Tools Add-On)

This right enables certain staff to send messages without consent if deemed necessary. An example might be communication during a disease outbreak.

Functionality

• A new right “Persons - Send messages without consent”.

• If the user has this right, when selecting one or more persons in the person list and sending an email or SMS, after a confirmation prompt (“123 of the 456 persons do not have consent...”), it’s still possible to send the message to all chosen persons.

• The send action is logged as a marketing activity on the person’s card, whether or not they have given consent.

Closed System for Blocked Persons (GDPR Tools Add-On)

Even persons who have unpaid debts or have been flagged for behavior that violates the agreement have the right to anonymization. The Data Controller can opt to place them in a closed system designed to prevent these customers from registering again.

Functionality

• Setting “Use closed system for blocked persons” enables this feature.

• Right “Persons - Closed system, block person” controls which users can mark a person as blocked.

• A person can be marked as blocked via a checkbox labeled “Permanently Blocked” on the person card’s Basic Info tab, if they’re flagged as suspended.

• During anonymization of a blocked person, that person is automatically added to the closed system.

• Right “Persons - Closed system, show anonymized blocked persons” controls which users can access Contact Register > Persons > Tools > “Anonymized Blocked Persons.”

• Users can permanently delete persons from the list of blocked persons.

• When attempting to register a person (phone or personal ID), the system automatically matches against the list and prevents registration if found.

• The same prevention applies for Internet Booking.

Procedures

Establish a clear policy explaining under what conditions you block a person. Consider including the policy in the agreement. Only grant a few people access to the list of blocked persons.

Information About Registered Personal Data (Basic Functionality)

Registered individuals should easily get information on which personal data is normally stored and how it is used.

Functionality

• A new message template “Personal Data Policy” that the Data Controller can write.

• Show the personal data policy in Internet Booking (Generation 2).

Procedures

Formulate a clear policy stating what is stored and how data is used.

Extract from the Person Register (Basic Functionality)

A Data Subject may request an extract of what is stored about them. Since it’s important that data not be given to the wrong person, the Data Subject should visit the facility for identification.

Functionality

• Setting “Extract from Person Register” enables the feature. Otherwise, staff can compile it manually (which takes longer but allows more control). (TP58715 / 2024.190301)

• Several system settings determine what should be included in the extract, depending on how the Data Controller interprets the regulation. These are in Settings > Category > GDPR, assuming GDPR Tools is enabled.

• The ability to choose what to include in the extract is part of the GDPR Tools add-on.

• Right “Persons - Allow extract from person register” controls which users can create such an extract.

• You can highlight a person, right-click, select “Extract from Person Register,” and save a file containing the data based on your settings.

• The fact that an extract was generated is logged.

Procedures

Set up a routine for how a person who requests an extract identifies themselves, who creates the extract, which information is included, and whether the info is handed over immediately or after a few days. Also decide how to deliver the file (paper, USB, etc.). Avoid sending personal data via email.

Handling Children’s Personal Data (Basic Functionality)

If a child is under 16, data processing is allowed only if a parent gives consent. Children appear in the system as participants in events (e.g., swim schools) where the booker is a parent, or as registered individuals (e.g., for subscriptions or service bookings).

Functionality

• By disabling the system setting “Require personal identity number for event participants,” you can still enable the event setting “Require event participants to have a person link” without needing the child’s personal identity number.

• By disabling the system setting “Require personal identity number for age checks on event participants,” you can do an age check for events with only the birth date—no personal identity number (Sweden only).

• If a person under a certain age (set by the system setting “Age to avoid needing parental consent at registration”) is registered via the simplified customer routines or from the person list, the system prompts for parental consent, logs the acceptance time, and references the employee.

• If a person under that age is registered via Internet Booking (Generation 2), the system asks for parental consent per the message template “Consent when registering children’s personal data,” logs the acceptance time, and the channel (“Internet Booking”).

Procedures

1. Configure age checks and person linking for events in a way you deem compliant with GDPR.

2. Create the message template “Consent when registering children’s personal data.”

3. Establish a routine for obtaining consent when a child is registered at the front desk. For example, you can laminate an A4 with the consent text.

4. If the parent withdraws consent, terminate all activities (subscriptions, bookings, etc.) and anonymize the child.

Right to Object (Basic Functionality)

A Data Subject has the right to object if personal data processing was done without an agreement or consent.

Procedures

If the Data Subject objects, correct or anonymize the registered data.

Persons Registered Before GDPR

If you updated your agreement in connection with GDPR, previously registered individuals have not read or agreed to it.

Procedures

Decide whether, based on a balancing of interests, you can simply inform previously registered persons about the new agreement and your data policy (e.g., via emails and signage) or if you need renewed consent from all registered individuals.

Right to Rectification (Basic Functionality)

A Data Subject has the right to provide new data if the existing data is incorrect, e.g., an incorrect name or address.

Functionality

If a first name, last name, or address is changed via Internet Booking, API, simplified customer routines, or Back Office, the System retains it and will not overwrite it during a scheduled person lookup. However, a manual person lookup can still overwrite it.

Procedures

If a rectification request is made, correct the erroneous data. If you export personal data to other systems, update those as well—unless it’s unreasonably burdensome.

The Right to Be Forgotten

A request for deletion must have a basis (lack of consent, etc.). The request is handled on-site, since staff need to verify ID.

Procedures

1. Verify ID.

2. Cancel and settle any subscription.

3. Mark the person for anonymization and finalize according to your procedures.

4. Personal data must be removed within 30 days.

Data Portability

This only covers data the individual personally provided (e.g., playlists in Spotify). Not profiling or automatically recorded data. We consider this request type to be inapplicable to the data stored in the System.

Automated Decision-Making

Needs limiting only if the rules significantly affect the person. We consider that the System does not contain such automated functionality.

Handling Contact Persons and Leads

If the person is not a customer or employee, you have no contract or consent for registering them. Only register them if you believe it may be permissible via a balancing of interests.

Immediately Noticeable Changes Upon Update

Most functions related to GDPR require enabling settings, but the following apply immediately after updating:

Back Office

• The right “Persons - Mark for anonymization” is required to mark one or more persons and click “Delete” to mark them for anonymization.

• Right-clicking a person in the person list offers new options:

  • Unmark anonymization

  • Complete anonymization

  • Extract from the person register

  • Accept agreement terms for registration

• “Permanently blocked” checkbox on the Basic Info tab of the person card.

• “Exclude from anonymization” checkbox at the bottom of the person card.

• “The registration agreement terms have been accepted” date field on the Marketing tab of the person card.

• “Find Inactive Persons” under Person List → Tools.

• Advanced Search → “Registration agreement terms have been accepted.”

• If a manual first name/last name change is made, it is not overwritten during the scheduled person lookup. It is overwritten after a manual person lookup on the person card.

• Ability to modify mass mailing consents on the person card or during registration.

Internet Booking (“Customer Web”)

• Ability to modify mass mailing consents on “My Pages” or during registration.

• Personal information is masked during person lookup.

Web-Based Service Bookings

• Personal information is masked during person lookup.

Additions to the API

Changes in API2

• When updating or creating a person, you can set the date/time they accepted the registration agreement terms. You can also retrieve this date by viewing the specific person.

Changes in API3

• When updating or creating a customer, you can set the date/time for acceptance of registration terms and retrieve the date by viewing that person.

• You can also indicate if the customer was registered with parental consent (this logs on the customer).

• You can request masked data in a person lookup.

• You can retrieve new message templates for Email, letter, and SMS consents; “Parental Consent for Registration,” “Registration Agreement Terms,” and “Personal Data Policy.”

• You can retrieve new settings for the default values of “Allow mass emailing by Email, letter, and SMS,” “Age at which parental consent is no longer required,” and “Require acceptance of registration agreement if not done after...”

Technical details are in the API documentation.