GDPR has brought increased attention to information organizations collect, transmit, and store about their donors, site users, and supporters. This document and the associated documents are designed to not only help ensure your organization is in compliance with GDPR, but also has a thorough understanding of its users’ data regardless of compliance.

Architecturally, each Capellic catalog is exists as an independent website. All website information is confined to its particular instance and is not shared or collected into any general database other than what’s required by services your organization requires (e.g., payment gateway). In other words, the data is yours.

This document breaks down information as it relates to your end-users in the following ways:

  1. What user data does the catalog collect, how is it collected, how is it used, and what is the process for removing user data?
  2. Where is the information stored and how long is it stored for?
  3. How do we keep your data secure?

This document does NOT include information that you are collecting that is out of Capellic’s control. This includes data collected and processed by third party services such as Google Analytics, Facebook tracking pixels, or A/B testing software solutions. It also does not include external services that you are using to store data and combine it with other user data outside of this platform whether its your organization’s CRM, database of record, or payment gateway.

That caveat aside, our tools and systems are designed to work in alignment with your procedures as we have no need for client-specific information. What we collect is used to facilitate needs by our clients whether its donating or collecting marketing information.


Capellic qualifies as both a “Controller and “Processor” as it relates to GDPR if your contractual relationship with us has Capellic as a SaaS provider.  If you use the catalog as a Drupal distribution then your organization is both “Controller and “Processor”. This document outlines the scenario where Capellic has a SaaS relationship with an organization.


Official definition (Article 4):“controller” means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.”


  • Capellic’s platform provides the means for processing personal data, whether it’s the check-out flow, account creation, or the payment gateway options (even if the specific payment gateway relationship and account is owned by the client).


Official definition (Article 4): ‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;


  • Catalog user account maintenance
  • Processing data necessary to send ecards to recipients on behalf of the sender/donor
  • Processing data necessary to send order complete, ereceipt emails to donors, and maintain order histories.
  • Sending necessary information to payment gateway to run some or all aspects of transaction(1)

User Data

Capellic collects many different types of information depending on how users arrive at the site and once they do once they get there. The following section outlines the types of data the platform collects, how it collects it, and why it is collected. A comprehensive list of collected user related data is available for clients here. Data collection is limited to the following:

1. Required User Supplied Data

This includes choices made or information supplied actively by user while shopping and is critical to maintain a usable shopping experience. (Clients may visit here for full list)


Required user supplied data is collected for four primary reasons:

  1. Critical to site performance and experience: This is typically information that is necessary to maintain or have a usable/successful shopping experience. Users expect, for example, to maintain a list of items in a shopping cart and product configurations (e.g., quantity, contact information, etc.) or to receive an email or tax receipt with details from their shopping experience once they complete their order.
  2. Critical to 3rd Party Integration: This information is required by 3rd party technology to ensure the site works correctly. Payment gateways (e.g., iATS, Stripe) and emails relay services (e.g., AWS SES, Sendgrid) require specific user supplied information to be able to complete their parts of the transaction experience.
  3. Support: This is information that is required so that our clients or Capellic on a client’s’ behalf can troubleshoot user problems while shopping, checking out, or any other capability the site offers.
  4. Client-specific Requirement: In many cases, our clients require certain user-supplied data to be collected. The reasons often vary, whether it’s to comply with local laws or for marketing purposes.


Capellic has no need for specific user data and does not collect it for its own purposes. In fact, our privacy policy expressly prohibits it. We do, however, occasionally collect anonymized (e.g., total donations, average donation, etc.) data to better understand and market how our features are being used.

2. Optional User Supplied Data

There are many features on the site that our users are not required to use. However, once a user decides to use the feature, there is information that is collected about them – some is required for the feature to work, other information is optional to the user. Examples include: creating an account, configuring ecards, creating Wish Lists or Group Gifts. (Clients may visit here for full list)


Optional User Supplied Data is collected in the following circumstances:

  1. User wants order/account control: Users may want to establish an account within the platform to better understand their experience. Having an account allows users to see their order history, “save a card to file”, or simply reduce the effort to check-out on their next visit.
  2. User wants to customize a product: Clients can customize and personalize certain products with messages and send directly to recipients either by email or through physical mail channels.
  3. User wants to create a Wish List or Group Gift: Features such as Wish Lists or Group Gifts require users to be logged in and user supplied data specific to their customizations to work. Wish Lists, Group Gifts, and user accounts, however, are not required to use the site. In addition, users buying off another person’s Wish List or Group Gift are not required to create accounts.
  4. User wants to contribute toward a Group Gift: Group Gift contributors can control whether their name shows as a contributor as well as the amount they donated towards the gift.
  5. Client-specific Requirement: In many cases, our clients want certain user-supplied data but don’t want to require that users supply it (e.g., title or how they heard about the catalog). The reasons often vary, whether it’s to comply with local laws or for marketing purposes.

Note on opting in to email updates

Catalog administrators can configure the email sign-up “opt-in” checkbox to be unchecked by default. The email opt-in, itself, relates only to how you communicate with site users and donors. For information for how to make this update, please contact your account representative.


Capellic has no need for specific user data and does not collect it for its own purposes. In fact, our privacy policy expressly prohibits it. We do, however, occasionally collect anonymized (e.g., # of Wish List creators, account creations, etc.) data to better understand and market how our features are being used. Capellic may occasionally promote a Client’s public Wish List or Group Gift through its email or social media channels if permitted by the contract with that organization.

3. Metadata

The catalog also collects data related to the user experience, user choices, and orders in a few specific ways that are not readily apparent to the user. In general, metadata is designed to provide context to existing user supplied information or to enable critical functionality.  (Clients may visit here for full list)


Metadata is collected in a few specific ways:

  1. Drupal cookies: Drupal sets a cookie for the session variable to enable various ecommerce activities and site behaviors, such as making it possible to link the user to the cart they have created. The cookie is set at the point the user adds a product to his/her cart. Drupal also sets a cookie to indicate whether the browser is JavaScript capable (see #1 in following session for further explanation).
  2. “Campaign” cookies: Clients who use the catalog’s “Campaign” feature may opt to enable cookies design to use campaigns to create customized user experiences on the site. “Campaign” information is a static value communicated to the site via specialized URL parameter “campaign=”. “Team” information is a static value communicated to the site via specialized URL parameter “team=”. These values are captured in a cookie through the duration of the site. If present, this data is associated with the donor orders. Catalog administrators can create Campaign and Team IDs at any time.
  3. “Source” cookies: Clients may choose to use the catalog’s cookie to capture the source of the traffic. “Source” information is a static value communicated to the site via specialized URL parameter “src=”. These values are captured in a cookie through the duration of the site visit. If present, this data is associated with the donor order.
  4. Payment Gateway Interactions: Payment Gateway services such as Stripe or iATS transmit data related to a donor’s order back to the catalog. This includes information about whether the order was successful or unsuccessful, tokens for refunding all or part of donations, transaction numbers, etc.
  5. Other Order Information: Along with essential data like product names and prices, a variety of other product information gets associated with user orders. This includes a history of tax receipts, product categories related to product, transaction date and time, etc.

A note on Google Analytics and other tracking services

We recommend that clients review what information they are transmitting to Google Analytics and other 3rd parties (e.g., Facebook tracking pixels) either through tracking pixels you’ve provided to Capellic for implementation or through Google Tag Manager containers. Whether information is collected by 3rd parties is completely in control of clients using the catalog and not the responsibility of Capellic or its catalog platform.


There are several reasons why metadata is collected and the context is necessary:

  1. Necessary to provide critical site functionality: Drupal cookies are required to make the catalog function like a catalog – to enable various ecommerce activities and site behaviors, such as making it possible to link the user to the cart they have created. Drupal cookies also let the site know whether the user’s browser can use JavaScript, which is an necessary part of various site functions.
  2. Requirement for essential third party service: Some metadata powers essential features such as the ability to refund a transaction, verify whether a transaction was successful or not (and why), or running a recurring transaction on behalf of the user.
  3. Support: Some metadata is essential for providing support and troubleshooting user problems using the site. This information may be necessary for both administrators and Capellic to help troubleshoot.
  4. Client need: Campaigns, source cookies, third party tracking pixels, and related metadata are designed to help organizations optimize their catalogs and gauge their performance.

4. Removing User Related Information

The catalog provides the tools for you to remove user data, whether Order information or account information in the instance it is necessary.


The only scenarios that Capellic will not be able to remove user data is from routine site/database back-ups.

If data related to ecard sending history must be removed, this request must be made via capellic’s support portal.

Data Storage

User data is stored in different places depending on the role of the information. Storage is divided as such:

Catalog Database

The application database stores all data related to user orders, user shopping carts, and activity requiring a user account (e.g., creating a Wish List, etc.).


  • User Login: End users of the catalog who create login accounts can see order and other data and content that they have created. There are no tools for exporting data for end users.
  • Administrative Interface: Client administrators with sufficient privileges (determined by client) and Capellic staff can access all user and order data.
  • Administrative Exports: Client administrators with sufficient privileges and Capellic staff can export user order data and associated metadata via export functionality designed to facilitate donation and personal data transfer to the client’s database of record and, if applicable, print card fulfillment houses.
  • CRM Integration: If requested by the client, basic user data can be transmitted dynamically to the client’s CRM via CRM APIs. This connection is implemented by client.


  • Order data: There is no set policy on data retention as rules and policies around order data areis our clients’ responsibility.
  • Inactive shopping carts: Shopping carts that have been inactive for 30 days are purged from the database .
  • Ad hoc data downloads: Capellic may occasionally download order or card fulfillment information in order to troubleshoot or provide support to a client. Capellic policy is to immediately remove these files once the client support request is resolved as there is no need to maintain the information.

Catalog User Session Cookies

A session cookie is set in the user’s browser at the moment they add the first product to their cart. The session cookies expires after 2,000,000 seconds (roughly 23 days) of inactivity. NOTE: This duration can be changed at the request of the client.

Catalog Hosting Provider

All catalog information is ultimately housed on the hosting provider’s servers. Capellic is moving from to Pantheon in June 2018. Details about are here. Details about Pantheon are here.  Additional information about Pantheon and GDPR can be found here.

There are a few specific places other than the live website where user data may resides:

  1. Host- run automatic backups:
    1. Daily snapshot is retained for a week.
    2. Pantheon: Daily snapshot is retained for a week and weekly backup is stored for a month.
  2. Capellic- runs manual backups: Capellic will backup the database before committing updates to platform functionality.
    1. Retained for at least a week.
    2. Pantheon: Retained for one month or six months, depending on administrator selection at the time of backup.
  3. specific back-ups: Capellic backs up site code and databases to Amazon Web Services. These backups are retained for a week. A bi-weekly backup is kept for three months.
  4. Multi-dev / development branches: Capellic creates development environments to provide support on behalf of the client, create testing environment for client to use, or to build out new features. These branches are deleted when no longer needed.
    1. When a multi-dev or development branch is created in, user (and ecard recipient) email addresses are anonymized.
    2. Pantheon: Within Pantheon, all identifiable user data will be anonymized.


Currently, only Capellic can access this data, as it is only designed to be used in emergencies.

3rd Party

  • Payment Gateway: Your payment gateway stores transaction- specific information including credit card, cvv, and expiration date. Note: Capellic does not store this information on its servers.
  • Tracking Services: Information you’ve collected via 3rd party tracking services such as Google Analytics, Facebook tracking pixels, or remarketing services may be stored within those services. We recommend checking to verify what level of user anonymity is accounted for within those services.

Data Security

Catalog Hosting

Site and data security are critical parts of how we evaluate and ultimately choose hosting providers. This includes the hosting providers’ knowledge and history of supporting Drupal websites and their specific security needs to how website code and database are updated to their internal processes and scans. Details about security, scans, etc. for our current host ( and our new host (Pantheon) are available here:


Capellic connects to our hosts in the following ways:

  • Connections may only be made via secure networks
  • Connections themselves must be secure via SSH keys and machine tokens
  • Internal policies prohibit user of public wifi connections
  • Internal policies require that work must only be done on Capellic issued hardware
  • Code managed and pushed to instances securely via secure upstream distribution


Users cannot access the server without specific action by Capellic within the or Pantheon instance control panel. Access to the host is only available to Capellic staff that require it for a specific business purpose. Access is removed when staff has no need to have access.

In addition, since each catalog is its own hosted entity, hosting administrators must be added to each catalog environment separately.

Finally, Capellic puts programmatic controls in place so that, when necessary, specific developers are only able to access development environments where all user data has been anonymized.

Drupal (Application Layer)

Capellic catalogs are architecturally isolated from each other, but work off a common code base that gets pushed from a central repository and then merged with the configurations and code (e.g., theme) that is specific to each specific client. The following controls are in place to ensure application- level security and user data privacy.


User data is isolated to specific client catalog instances. In other words, data from one catalog cannot be accessed from another catalog. The databases and websites that relate to them are completely separate. In addition, no client data exists in the central code repository.


All user identifying information is anonymized when creating development or test environments specific to a client catalog.


Capellic catalogs have varying tiers of access both internally at Capellic and to its clients. Capellic’s administrators have access to all catalog features, data, and configurations. Capellic limits client access to Drupal features that have a significant impact on security (e.g., the ability to change code) to Capellic staff only. Capellic also requires that its own administrators maintain separate logins to each of its client catalogs ensuring access to one does not allow for access to another.

Catalog clients are empowered to manage their own administrators’ and site users’ access. We recommend that clients regularly review who has access and to what within the system.


All updates to code and to the database are checked in and documented as part of the go live process. This gives granular reporting on every change made to our platform and each client catalog. These change logs are reviewed and verified by other staff developers.


The Drupal Security Team regularly releases security-specific updates to Drupal core and to supported contributed modules. Details about the Drupal Security Team, recent security updates, etc. is available for review at anytime here. When these updates are released, Capellic reviews the updates and the associated threat/risk level and applies the security updates as necessary –- often within minutes of the release.


Capellic runs monthly vulnerability scans and quarterly PCI scans via Trustwave. Vulnerabilities are reviewed and, if applicable, addressed according to their severity.


An important note is that Capellic does not monitor code introduced via Google Tag Manager (GTM) other than the scans listed above. Given the ability for tools such as Google Tag Manager to introduce code that can override existing site code, we strongly urge clients to regularly review the code added to GTM containers and who has access to these containers. We recommend the same level of diligence for other 3rd party tools that code onto the platform.

Incident Reporting and Processes

Capellic will respond in accordance to rules and policies as outlined here as a best practice. However, reporting to ICO is only relevant if a user data incident is of sufficient severity and specifically impact users in the European Union (EU).

“High Risk” Data: In general, Capellic catalogs do not store any data that it classifies as “High Risk”. However, Capellic’s policy is to notify clients in instances of unauthorized access to user data in accordance to the policies detailed in the link above and, more importantly, in the event that a breach results in the introduction of code designed to collect user credit card information.

(1) Capellic’s role as a processor varies by payment gateway and integration method. Implementations methods such as Direct Post means that Capellic does not touch or process credit card information, but does process whether or not the transaction was successful. External payment methods such as PayPal’s ‘Payment Express’ send users offsite – Capellic does not touch or process credit card information, but does process whether or not the transaction was successful. Other payment gateways have APIs to run transactions. In this scenario, the credit card information may temporarily (i.e., seconds or minutes) reside in server memory while in transit to the payment gateway for processing, thereby making Capellic more involved as a processor. API integration methods means that Capellic will also process whether or not the transaction was successful. All methods allow for the platform to initiate recurring gifts and refunds.

Rev: CV2018-05-23