%20(1).svg)
SaaS Privacy Policy
1. Responsibility and privacy contacts
FutureNext GmbH
Mafinex Technologiezentrum
Julius-Hatry-Str. 1
68163 Mannheim, Germany
Privacy contact: support@virtualbadge.io
External data protection officer: heyData GmbH, Schützenstraße 5, 10117 Berlin, Germany; datenschutz@heydata.eu; www.heydata.eu
Processing for our own purposes
FutureNext is the controller for customer accounts, subscriptions, billing, business communications and general support correspondence, and for its own authentication, platform security and troubleshooting. Section 6 explains the legal bases.
Processing for an issuing organisation
The issuing organisation determines why recipient, credential, course and attendance information is used and which services it selects. We act as processor on its instructions to create and deliver digital credentials, provide access and validation, operate course forms and attendance workflows, and produce issuer reports. This includes the diagnostics, audit records and authorised support access needed to provide and protect those services.
The issuer's privacy information explains its legal basis, data sources, required fields, visibility settings and retention. If it acts for another organisation, it must identify the responsible controller. This notice supplements that information.
2. Our services and who this notice is for
This notice covers the Virtualbadge.io SaaS platform and applies to authorised account users and business contacts, credential recipients, course participants and people checking credentials. Recipient access and validation do not require a Virtualbadge.io account.
| Service | Audience and function | Further information |
|---|---|---|
| Issuer administration portal | Account owners, administrators and editors manage templates, recipients and issuance. | Issuer administration |
| Recipient credential page | Recipients access credentials through an emailed link. | Credential access |
| Credential validator | Recipients and other visitors check credential validity. | Validation |
| Course participant forms | Participants provide information for attendance documentation and issuance. | Participant forms |
| Zoom integration | Issuers connect meetings or webinars to credential templates. | Zoom integration |
The validator is also available on our website and embedded in client websites. This notice covers the credential service; the surrounding website's notice covers its separate processing.
Marketing-website visits, sales enquiries and newsletter subscriptions are covered by our Website Privacy Policy. Email engagement measurement is also described in section 5.
3. Information and purposes by service
3.1 Issuer administration
| Activity | Information and purpose |
|---|---|
| Accounts and access | Names, work contact details, organisation, roles, permissions, preferences, account identifiers and authentication information, to register users and manage access. |
| Subscriptions and billing | Billing details, subscription and transaction identifiers, invoices, payment status and correspondence, to administer subscriptions and meet accounting obligations. |
| Support and communications | Contact details, messages, attachments and account context, to answer requests and communicate about the service. Issuer-controlled credential content remains subject to issuer instructions. |
| Troubleshooting and security | Request/error records, IP addresses, browser/device details, timestamps, relevant identifiers and successful or failed authentication events, to diagnose problems and prevent misuse. |
Information comes from account users, business contacts, authorised colleagues or their organisations, selected identity providers including Microsoft, payment services and service interactions. We use authentication information to provide account access.
Issuers enter, upload or import recipient names, email addresses, credential content and additional fields. We process these with template/file identifiers, dates, validity status and delivery records to create and manage credentials. Audit records identify authorised actions, the user responsible, affected records, timing and technical context.
Additional content may include signatures, images or sensitive information. The issuer is responsible for the applicable legal conditions and safeguards, including the necessary rights to images and other content it uploads.
3.2 Receiving and accessing credentials
Recipient email addresses are used to deliver issuer messages and access links. The recipient page uses access identifiers, recipient names and emails, credential content, dates, status and technical requests to display credentials. These details normally come from the issuer or its connected systems. The page also has a separate privacy notice.
Depending on the issuer's configuration, recipients can download or share credentials, add them to a digital wallet or provide a profile image. Downloaded files and embedded metadata can contain more personal information than the validation summary.
Issuer reports record delivery status, access, downloads, sharing, wallet and LinkedIn profile-add actions, validation-link use and issuer-configured button activity. Records include recipient/credential identifiers, timing and browser, device and language details. Recorded clicks do not confirm completion of an external action.
Delivery and bounce records support email delivery. Where enabled, separate engagement records measure opens when images load. Image blocking or automatic loading can affect their accuracy. Open measurement is separate from delivery status and browser activity reports.
3.3 Credential validation
The validator checks a credential identifier or link against the issuer's record. Results can show the recipient's name, issuer, credential title and description, issue/expiry dates, validity status and a preview. Descriptions and previews may include additional personal information.
For PDF signature checks, the file is sent to our verification service. It is checked without being saved as a new credential file.
Connection and diagnostic records support operation and security. The same validation process applies to website embeds.
3.4 Course participant forms
Forms collect participant names, email addresses, course or credential selections and issuer-requested information. This may include organisation/contact details, date of birth, answers, declarations and a drawn signature. The issuer or trainer may pre-enter information for participants to complete.
Authorised trainers, administrators and approvers use submissions to document attendance and issue credentials under the configured approval process. Required fields are identified on the form; missing information can prevent attendance documentation or issuance.
Where configured, reports, attendance documentation and credential files are delivered to the trainer or other recipients selected by the issuer. Separate course-record retention is explained in section 10.
3.5 Zoom integration
When an issuer connects Zoom, we process account identifiers, authorisation credentials and meeting/webinar settings. Zoom supplies registration and attendance details, including names, emails, join/leave times, attendance duration and registration answers.
We use this information to assess the issuer's attendance criteria and issue credentials automatically, with email delivery where configured. Section 7 explains the automated processing.
The integration uses registration and attendance reports; it does not import recordings, audio, video or chat. The issuer determines its use of Zoom under its Zoom agreement and privacy information. Zoom's own processing is explained in its Privacy Statement.
4. Visibility, browser technologies and choices
Access to credentials and public validation
Recipients access their credentials through an emailed link without needing a Virtualbadge.io account. Anyone with the link may be able to view the associated information. Links have no fixed expiry date and should be kept private. Issuers can enable email verification for individual templates.
If the issuer enables online validation, anyone with the credential identifier or validation link can check the credential. The issuer determines what information is visible. Contact the issuer about correction, restricted access or deletion.
Cookies, browser storage and measurement
Cookies and browser storage support authentication, credential access, preferences and form/editor state. Issuer authentication-cookie lifetimes are listed below, subject to renewal and logout. Recipient access cookies last 15 minutes. Form session storage normally lasts for the browser-tab session; local preferences remain until replaced or cleared.
Issuer pages can contain the following cookies. Authentication periods reflect service configuration; HubSpot periods follow its published documentation.
| Cookie | Purpose | Category | Lifetime |
|---|---|---|---|
vb_access_token | Authenticate issuer account access | Necessary | Five minutes |
vb_refresh_token | Renew issuer account access | Necessary | Up to 14 days |
__hssc | HubSpot session measurement | Analytics | 30 minutes |
__hssrc | HubSpot recognition of a new browser session | Analytics | Browser session |
__hstc | HubSpot visit and session history | Analytics | Six months |
hubspotutk | HubSpot visitor recognition and association with form-submitted contact information | Analytics | Six months |
Shared-domain measurement cookies may also be present after marketing-website visits. The website notice explains the related analytics and advertising. This table is not a complete inventory for all five services.
Microsoft Application Insights collects page activity, performance and diagnostic information on issuer, recipient and course-form applications; the Zoom frontend also contains this integration. Information can include page/request details, service identifiers in links, browser/session identifiers, device context and errors. Issuer reporting and Jimo/HubSpot functions are described in sections 3 and 5.
Required information and younger recipients
Account access, subscriptions and requested support require the information necessary for those functions; without it, they may be unavailable. Billing details may also be required by law. The issuer explains its course and credential requirements.
Issuer administration is intended for organisations and authorised personnel. Recipients may include children; the issuer must provide age-appropriate information and establish the necessary legal basis and safeguards.
5. Providers we use
Provider roles depend on the activity. Inclusion in this table does not make every provider a subprocessor for all issuer-controlled information.
5.1 Service providers
| Name | Function | Data location and processing |
|---|---|---|
| Bird B.V. | Email delivery infrastructure for sending certificates | EU |
| Jimo Technologies, Inc. | Access to a public roadmap with interaction options | EU |
| Microsoft Ireland Operations, Ltd. | Scalable cloud infrastructure | EU |
| HubSpot | CRM, contact research and email automation | EU |
| Stripe Payments Europe Limited | Payment processor | International data processing, including in the United States. International transfers are safeguarded by the EU-US Data Privacy Framework. |
| Hetzner Online GmbH | Hosting and server infrastructure for operating the platform | EU (Germany) |
| Cloudflare, Inc. | Bot and abuse protection (Turnstile) | EEA and United States |
The stated data locations identify service or processing regions for the respective providers. They do not rule out additional international access or processing; see section 8.
5.2 Service communications and documents
Account and service messages are separate from optional marketing. HubSpot email measurement can record opens and link clicks, including for non-account addressees. Marketing permissions and unsubscribe choices are covered by the website notice. Permission to send an email does not itself authorise engagement measurement.
Current subprocessor information is available through support@virtualbadge.io. Data processing and security documents are described in section 13.
6. Grounds for processing
Where FutureNext acts as controller:
| Purpose | GDPR basis |
|---|---|
| Accounts, subscriptions and requested support | Article 6(1)(b) where necessary for a contract with the person concerned. For organisation representatives, Article 6(1)(f): administering the business relationship, access and assistance. |
| Statutory accounting and tax records | Article 6(1)(c): applicable German recordkeeping duties. |
| Our own authentication, platform security and troubleshooting | Article 6(1)(f): protecting access, preventing misuse and maintaining reliable operation. Issuer-instructed diagnostics remain processor activities. |
| Necessary legal-claim records | Article 6(1)(f): establishing, exercising or defending claims. |
| Optional browser or email measurement for our purposes | Article 6(1)(a) where consent is required. The purpose and basis for recipient-derived reuse remain to be confirmed. |
For issuer-instructed processing, the responsible organisation establishes the legal basis and any additional conditions, including for its reporting and publication settings. Our contract with the issuer does not itself provide a legal basis for every recipient.
7. Automated processing and credential eligibility
The Zoom workflow matches attendance by participant email, combines attendance across joins and excludes waiting-room time. It compares attendance with the issuer's minimum minutes or percentage of scheduled duration and can issue credentials automatically. Missing reports or matching errors can affect issuance. Participants can ask the issuer to review attendance, eligibility or credential information they believe is incorrect.
Where a decision has legal or similarly significant effects and Article 22 GDPR applies, the issuer must establish a permitted basis and provide the required explanations and safeguards, including applicable human review and challenge rights.
8. Sharing, integrations and international transfers
Authorised issuer users, trainers and approvers receive information according to their permissions. Service personnel and providers access information to perform their tasks. Issuer-directed reports, exports and credential deliveries go to the recipients or systems it selects. Issuer-enabled APIs, connectors and webhooks can import or export recipient, credential and course information. These imports include recipient information supplied through Zapier. The issuer selects the connected systems and is responsible for the necessary permissions and privacy information for that workflow. Connected services have their own privacy notices.
Recipient-selected sharing, profile and wallet functions connect to services such as LinkedIn, Facebook, X, WhatsApp, Apple Wallet or Google Wallet. Information may include names, profile details, credential content, issuer, dates and validation links. Previously authorised social connections can retrieve profile information on later visits. Recipients may also manually share downloaded credential images through Instagram. Destination services and issuer-linked websites apply their own notices; externally held copies follow their holders' retention arrangements.
Advisers, courts and authorities may receive information where a lawful disclosure is necessary.
Transfers outside the European Economic Area
Primary Azure stores are in Germany and the Netherlands, and our selected HubSpot hosting region is the EU. Global delivery, support, provider operations and selected integrations can involve the United States and other countries.
Transfers require an applicable adequacy decision or safeguard. The EU–US Data Privacy Framework can cover transfers to currently certified US recipients within its scope. Other transfers may require EU standard contractual clauses and supplementary measures. You can request information or a copy of applicable safeguards through our privacy contact, subject to necessary redactions.
9. How we protect information
We use access controls, authentication, monitoring and recovery measures to protect information according to the risks. Personnel handling issuer-controlled information must be bound by confidentiality and processing instructions. Security documentation is available through section 13.
10. Retention, return and deletion
Retention depends on the purpose, the issuer's instructions and applicable legal obligations.
Credential and course information. The issuing organisation determines retention for its services. Expiry and revocation change a credential’s validity and display. Neither these actions nor subscription cancellation automatically delete records, files or personal information. Continued validation requires continuing instructions. At the end of processing, Article 28 GDPR requires return or deletion at the responsible controller's choice, including deletion of copies unless EU or Member State law requires storage. Course records are retained separately from credentials.
Account and business records. Closing an account does not delete all related records. Legal retention periods are generally six years for commercial correspondence, eight for invoices and ten for books and financial statements, usually from year-end. Statutory extensions may apply under section 257 HGB and section 147 AO.
Technical records. Application telemetry has a 30-day retention period.
Core database backups. The core database has a 14-day recovery window. Deleting information from the live database does not immediately remove it from existing backups.
11. Privacy rights
For FutureNext's controller processing, contact support@virtualbadge.io to request access, rectification, erasure, restriction or portability where the legal conditions apply. Portability covers information provided by the individual and processed automatically on consent or contract grounds. Consent can be withdrawn at any time without affecting earlier lawful processing.
You may object, for reasons relating to your particular situation, to processing based on legitimate interests. You may object to direct marketing at any time, including related profiling.
For issuer-controlled credential, course or attendance information, contact the issuer. We can help identify the responsible organisation, forward requests and assist on its instructions. Identity checks must be proportionate. A response is generally due within one month; extensions for complex or numerous requests require timely explanation.
Independent providers also give rights contacts in their linked notices.
You may lodge a complaint with a data protection supervisory authority.
12. DPA and security documents
Our data processing agreement (DPA) and information about technical and organisational measures are available on request through support@virtualbadge.io.
13. Privacy enquiries
Contact support@virtualbadge.io with questions about this notice or our processing. For issuer-controlled information, follow the route in section 11. External DPO details are in section 1.
