When multiple respondents are assigned an assessment who can submit the assessment for review

1. You are here:
2. Handbook
3. Marketing
4. Marketing Operations
5. OneTrust

On this page

Uses

OneTrust is privacy, security, and data governance software that marketing uses as our privacy and compliance solution on our websites. The marketing operations team works closely with our legal team and is primarily responsible for our privacy and compliance on our websites including cookie preferences.

Support

1. Technical assistance: Slack #mktgops
2. Support Portal (requires seperate account/login)
4. Cookiedatabase.org
5. Cookiepedia

Access

To access OneTrust, please create an access request. OneTrust is provisioned through Okta SSO via a Google group. A user is added via the Google group which is directly connected to Okta SSO and OneTrust. All users are added as a Project Manager. Please specify the role needed in OneTrust in the access request so it can be updated once you have access. See system default roles available below.

Training

Cookie Compliance module

1. Scanning a Website, Categorizing & Maintaining Cookies Implementation Webinar
2. Configuring Cookie Compliance Banner, Preference Center & Geolocation Rules Implementation Webinar
3. Script Integration - Publishing the Cookie Banner Script Implementation Webinar
4. Cookie Blocking - Blocking Cookies via Tag Managers and HTML Implementation Webinar

Data Subject Access Requests (DSAR) module

1. Kick-off call recording 20210106
2. Workshop recording 20210111

System default roles

1. Assessments Manager: Assessments Managers are business users who have access to most everyday and some administrative functions in the Assessment Automation module. By default, Assessments Managers have limited access to destructive and configuration functions.
2. Audit Manager: Audit Managers are business users who have access to most everyday and some administrative functions in the Audit Management module. By default, Audit Managers have limited access to destructive and configuration functions.
3. Auditor: Auditor users are business users who have access to a limited set of functions in the Audit Management module. By default, Auditors can contribute to workpaper results and log findings and have no access to destructive and configuration functions.
4. Awareness Training Learner: Awareness Training Learners are low-level users who can only access training courses that have been assigned to them. Awareness Training Learners do not have access to any administrative functions.
5. Awareness Training Manager: Awareness Training Managers are business users who have access to most everyday and some administrative functions in the Awareness Training module. By default, Awareness Training Managers have limited access to destructive and configuration functions.
6. Consent Manager: Consent Managers are business users who have access to most everyday and some administrative functions in the Universal Consent & Preference Management module. By default, Consent Managers have limited access to destructive and configuration functions.
7. Cookie Manager: Cookie Managers are business users who have access to most everyday and some administrative functions in the Cookie Compliance module. By default, Cookie Managers have limited access to destructive and configuration functions.
8. Data Mapping Manager: Data Mapping Managers are business users who have access to most everyday and some administrative functions in the Data Mapping module. By default, Data Mapping Managers have limited access to destructive and configuration functions.
9. Data Subject Requests Manager: Data Subject Requests Managers are business users who have access to most everyday and some administrative functions in the Data Subject Requests module. By default, Data Subject Requests Managers have limited access to destructive and configuration functions.
10. Enterprise Policy Manager: Enterprise Policy Managers are business users who have access to most everyday and some administrative functions in the Enterprise Policy module. By default, Enterprise Policy Managers have limited access to destructive and configuration functions.
11. Incidents Manager: Incidents Managers are business users who have access to most everyday and some administrative functions in the Incidents module. By default, Incidents Managers have limited access to destructive and configuration functions.
12. Invited: Invited users have minimal access to the application. By default, Invited users can only access assessments which they have been invited to complete. The application is only accessible to these users through the link provided to them via email. Invited users are added by email address from an assessment. Invited users cannot be created on the Users screen.
13. IT Risk Manager: IT Risk Managers are business users who have access to most everyday and some administrative functions in the IT Risk Management module. By default, IT Risk Managers have limited access to destructive and configuration functions.
14. Maturity & Planning Manager: Maturity & Planning Managers are business users who have access to most everyday and some administrative functions in the Maturity & Planning module. By default, Maturity & Planning Managers have limited access to destructive and configuration functions.
15. Privacy Notice Author: Privacy Notice Authors are business users who have access to creating, viewing, and editing all privacy notices. By default, Privacy Notice Authors have no access to destructive and configuration functions.
16. Privacy Notice Manager: Privacy Notice Managers are business users who have access to most everyday and some administrative functions in the Policy & Notice Management module. By default, Privacy Notice Managers have limited access to destructive and configuration functions.
17. Privacy Notice Viewer: Privacy Notice Viewers are business users who have access to viewing current versions of privacy notices. By default, Privacy Notice Viewers have no access to destructive and configuration functions.
18. Privacy Officer: Privacy Officer users are high-level users who have access to most functions in the application. By default, Privacy Officer users do not have access to administrative and destructive functions such as audit logging, deletion, and integrations.
19. Program Benchmarking Manager: Program Benchmarking Managers are business users who have access to most everyday and some administrative functions in the Program Benchmarking module. By default, Program Benchmarking Managers have limited access to destructive and configuration functions.
20. Project Owner: Project Owner users are business users who have access to everyday functions in the application. By default, Project Owner users have limited access to administrative, destructive, and configuration functions. Project Owner users can launch assessments, review inventory data, view scan results, and complete other everyday business tasks.
21. Project Respondent: Project Respondent users can create a password to log into the application and access a list of all assessments assigned to them. Project Respondents can be assigned assessments, risks, and needs more information requests, respond to assigned assessments, and add comments to assessments.
22. Project Viewer: Project Viewer users have read-only access to the application. By default, Project Viewer users can view information, but cannot make any changes or respond to assessments. Project Viewer users cannot be selected as the respondent for an assessment.
23. Site Admin: Site Admin users have complete access to the application. By default, all permissions are enabled for Site Admin users.
24. Vendor Manager: Vendor Managers are business users who have access to most everyday and some administrative functions in the Vendor Risk Management Module. By default, Vendor Managers have limited access to destructive and configuration functions.

Custom roles can also be created. More in this support article (login required).

Implementation

See the epic for more information.

Cookie Compliance

Scanning a Website

The scanner simulates a user from Ireland (where OneTrust servers are located).

1. Navigate to the cookie compliance module via the "home screen" after login and clicking on the cookie compliance tile or by clicking the "launchpad" icon in the top left corner next to the home icon.
2. Click the Add Website button.
3. Best practice: Add the root domain to scan without www. If you scanned a domain with www it will not capture domains with prefixes.
4. Choose the GitLab organization to assign the domain scan to.
5. Under More Details, you have additional options to use in the scan including limiting the scan to a number of pages (default is 1,000), limiting to a specific path within the site, clearing previous scan history, scanning pages with query parameters, targeting pages to scan within the site, or including sitemaps URIs.

Website scan menu

In the list of websites that have been scanned, you can hover over any domain and click the 3-dot icon on the right-hand side. Clicking this icon provides additional options for that particular website scan including:

1. Re-scan: re-scans the website and provides additional options for the re-scan.
2. Re-process
3. Reassign: reassign to a different organization
4. Login: This option gives you the ability to scan behind a login or webform; if clicked, you'll be redirected to the website details to provide additional information; you can gather the web form HTML attributes by using the Inspect feature in Google Chrome
5. Schedule: schedule a future scan (default: every 3 months for every quarter of the year); option to notify a user once completed
6. Stop: stop a pending scan
7. Delete: delete a scan
8. Export scan results
9. Get help

Configuring a Website Scan

More scan details

1. Limit scan to 1000 pages: If you want to limit the scan to a number of pages. Note that as you increase the amount of pages to scan, the longer the scan will take to complete.
2. Limit to this path within site: OneTrust considers about.gitlab.com/fr and about.gitlab.com 2 separate domains with this option enabled.
3. Clear previous scan history: Does not delete previous data; scanner treats the domain as if its the first time scanning; (use case: significant cookie or design change on the website)
4. Scan pages with query parameters: scan URLs with query parameters (ex: about.gitlab.com?utm_source=marketo); Input field example: name=first,name=last. Separate multiple parameters with commas. The scan will search through the domain with those noted parameters. Ensure the domain you enter includes ? at the end of the URL.
5. Target pages to scan: Input exact URL site with full https:// ; use case: certain pages that might not be accessible to users or you want to scan this specific web page. For multiple pages, add a line break.
6. Sitemap URIs: Input sitemap URL with https:// with .xml.

Scheduling Cookie Scans

1. From the website scan menu, highlight the domain you wish to create scan schedule for.
2. Click the 3-dot menu.
3. Select Schedule.
4. The default is set to every 3 months for every quarter of the year; You can also select a specific date.
5. Optional: enter an email address to notify a user once a scheduled scan is completed.

Viewing Scan Results

When a scan is completed, you can view the results by clicking into the scan from the Websites menu. You'll be taken to a scan dashboard that visualizes the results of the scan which includes information about:

1. Tracking technology
2. Cookies with category
3. Tags
4. Forms
5. Pages
6. Local storage

On the Show dropdown, you can view a summary of all scans for that particular domain and view previous individual scans with a date/time stamp.

From the main scan results page, you can also select these 6 categories to dive further into those specific results.

Cookie scan results

View categories of cookies including the name of the specific cookie. This information comes from and is compared to OneTrust's cookie database (cookiepedia.co.uk). You can export these results by clicking Export in this view. After clicking Export you can choose the specific scan to export results from. When the export is ready for download, a notification will appear within the OneTrust tenant as the bell icon in the top-most menu.

Exporting Scan Results

From the bell icon, you can download the results (.xlsx).

Categorizing Cookies

1. Navigate to Categorizations in the left-hand menu of the cookie compliance module.
2. Click Categories.
3. Clicking the arrow on a respective category will expand the description of this cookie category. This description is what users will see.
4. Click the pencil icon to edit the cooke category description. Important: You must confer with the GitLab legal team before updating these descriptions as they must strictly align with our policies regarding cookie use.

These cookie categories are standard and the defaults provided by OneTrust:

1. Strictly necessary cookies ID C0001: the website needs these cookies in order to function properly (example: identify items placed into a shopping cart)
2. Performance cookies ID C0002: get information about how site visitors are using the website (example: Google analytics)
3. Functional cookies ID C0003: provide additional enhancement of the experience of site visitors (example: language selector for localization)
4. Targeting cookies ID C0004: cookies that attempt to gather more information about a user in order to personalize marketing (example: remarketing)
5. Social media cookies ID C0005: social media services added to the site that enable users to share content with their friends and networks easily

You also have the ability to create a new cookie cateogory.

Cookies in the Unknown category need to be categorized manually with help from developers, third-party vendors, or through a Google search.

Adding, Editing, and Removing Cookies

1. Navigate to the Cookies tab under the Categorizations menu.
2. View the list of cookies that have been identified and categorized, including the domain where it was identified, the lifespan of the cookie, the hostname, and the description.
3. Click into each cookie individually to view more information about that cookie.
4. In the Edit Cookie overlay, you can select a different category for the cookie, add a description for the cookie, update the lifespan of the cookie, note whether it's a first-party or third-party cookie, and select the domains to manually assign the cookie to. Changing the lifespan of the cookie is for auditing purposes and does not change the functionality on the website.
5. Manually add a cookie to a particular domain if you don't wish to run the domain through a scan in order to pick it up. Click Add Cookie to manually add a cookie and input all the information regarding that cookie from step 4. Note: Host is not necessarily the domain where the cookie is but where the cookie is hosted. This will not add the cookie to the domain you input, but rather an exisiting cookie on the domain that is not part of the audit.
6. You also have the option to bulk categorize cookies by selecting multiple cookies from the list. Select all cookies or specific cookies from the list, then click the double-arrow icon to bulk edit the categories of those cookies.
7. Use the search bar to search for specific cookies by the cookie name or the host name.
8. Use the filter icon to filter down to specific types of cookies by their category, domain, lifespan, or hostname (example: only view functional cookies).

Adding, Editing, and Managing Cookie Compliance Templates

Base templates

1. Generic Cookie Banner: template that is not specific to a framework. It is meant to be used to create a global template.
2. GDPR (General Data Protection Regulation): template with only cookie categories. You may enable IAB at any time. This template is GDPR compliant.
3. IAB Transparency and Consent Framework 1.0: template for IAB Transparency and Consent Framework 1.0 based on recommended settings from the policy's user interface guidelines. This will sunset in the first half of 2020.
4. IAB Transparency and Consent Framework 2.0: template for IAB Transparency and Consent Framework 2.0 based on recommended settings from the policy's user interface guidelines
5. CCPA Template (California): template with verbiage, category groupings, and settings that match more closely with the California Consumer Privacy Act.

Add new template

1. Click Templates.
2. Click Add New Template.
3. Select framework and laws that apply to the site.
4. Name the template.
5. Choose the GitLab organization.
6. Add the default language.
7. On the next screen, configure the layout, styling, content, and behavior fo the cookie banner. The right pane shows a preview of the cookie banner.

Customizing the Banner Template

Layout options

Most popular: Flat, bottom position

1. Center rounded
2. Flat
3. Floating flat
4. Floating rounded
5. Floating rounded corner
6. Floating rounded icon
7. Position: bottom or top

Styling options

Colors are in RGB or hexadecimal code.

1. Accept & reject button color
2. Button text color
3. Text color
4. Background color
5. Link text color
6. Accordion background color
7. Manage preferences button color
8. Manage preferences link color

There are also options for custom CSS (not available in preview).

Content options

1. Title & description (HTML supported) - the description may need customizing to match the consent model for the site, so as not to risk misleading visitors.
2. Cookie policy link (link text and URL)
3. Button set: show allow all button, show cookie settings button, cookie settings button name, cookie settings button style (link or button), show reject all button, show close button

Behavior options

1. Require banner interaction: displays overlay that forces a choice by the visitor

Manage languages

Select the languages which you want to localize the cookie banner to. Also select the default language. You can set up different cookie banner options by language. Ensure that the language matches our policies. Toggling the show advanced langauges option shows country-specific versions of languages.

Preference center

In styling, you can choose to override the styling from the cookie banner to have a different styling for the preference center. This includes an option to add a logo and changing the accordion type for the cookie categories.

Notice there are different options in the preference center under layout as well. Depending on the options chosen, some features may not be available (example: choosing the tab layout removes the accordion feature for the cookie categories). Custom CSS is also available for the preference center.

There are options for WCAG (Web Content Accessibility Guidelines) best practices for accessibilty in the preference center.

Advanced configuration

1. Toggle Show cookies list to show a link to the user with cookie details related to the category they selected in the preference center.
2. Select whether you want to show the user the various information about specific cookies including host, duration, type, category, and description. There are options here for linking to Cookiepedia as well as allowing the user to opt-out of a particular cookie host.

You can group the cookie categories as well as adding another group of cookie categories for a better user experience (example: new group called "ads" with the targeting and social media cookie categories grouped underneath).

Cookie list

This is the comprehensive list of cookies that is available to the user to view. In styling, you can adjust color options for title, cookie group name, table header text, table header background, and primary text. Toggle the table format on or off. There are options for custom CSS here as well. In content, you can adjust the options for the cookie list title, description, host, cookies column, and cookies used label. Toggle the show lifespan on or off.

Ensure any changes you make are approved by legal and saved within the OneTrust tenant.

Adding, Editing, and Deleting Geolocation Rules

1. Click Geolocation Rules in the cookie compliance menu.
2. A Default Consent Policy exsits out of the box.
3. Click Create New to create a new geolocation rule group.
4. Name the rule group.
5. Choose GitLab organization.
6. Enter a description.
7. In the rule group details, a default global rule exists which would apply these settings globally regardless of country. To add a country or region specific rule, click Add rule and update the options accordingly.
8. Name the rule. (example: GDPR)
9. Select the regions you would like to assign the policy to. Multpiple regions can be included for a specific rule. Note: Geolocation for mobile devices uses coordinates reported by the internet-connected device. Users at or near borders may experience reduced accuracy for this function.
10. Toggle Show Banner on or off. If unchecked, no banner will display but settings take effect.
11. Input the template to use for this geolocation rule.
12. Choose the consent model for this geolocation rule. Clicking the dropdown here, you can select a consent model for all cookie categories or specify the consent model for each cookie category. Toggle Do Not Track by the cookie category.
13. In Behaviors you can toggle the behavior for this rule in conjunction with the cookie banner and whether that paritcular behavior will accept all cookies or not as well as closing the banner.
14. Reconsent will occur after: this will prompt the banner again for users to capture reconsent. The default is 1 year but can be configured by months, years, and days.
15. Capture records of consent: cookie ID associated with each user; the consent module logs those preferences.
16. Advanced analytics: sends browser type, device type, and country where the user consented. This information will be shown in the dashboard. Toggle this to a specific cookie category (example: performance cookies for Google analytics).

Assigning a Geolocation Rule Group to Domains

Assigned domains

1. Click Assign to Domains.
2. Select the domains you would like to assign the geolocation rule to.
3. Click Assign.

Consent models

1. Opt-in consent model: If you select Opt-in, all cookie categories (besides Strictly Necessary) will be set to Inactive. These cookies will not be set on the visitor's device unless they are enabled in the preference center.
2. Opt-out consent model: If you select Opt-out, all cookie categories (besides Strictly Necessary) will be set to Active. These cookies will be automatically enabled when the visitor lands on the website. The website visitor can disable the non-Strictly Necessary cookies in the preference center.
3. Implied consent: all cookie categories (besides Strictly Necessary) will be set to Inactive Landing Page. These cookies are not set until the website visitor clicks the OK button on the cookie banner or continues browsing the website. The website visitor can disable cookie categories in the preference center.
4. Notice only: If you select Notice Only as the default consent model, all cookie categories will be set to Always Active and cannot be disabled by website visitors. A banner informing the visitor that the website uses cookies will be displayed on the landing page of the website.
5. Custom: If you select this option, you can set a different default status for each category of cookie on your site. You can customize the consent model to suit your organization's needs and can set the Do Not Track status for each category of cookie.

Accessing Scripts

1. To access the scripts, click Scripts in the left menu of the Cookie Compliance module.
2. Click the domain where the script will be implemented.
3. Any time a change is made to a domain within the OneTrust tenant, those changes must be published to production in order for the users to see those changes reflected in the cookie banner, preference center, etc.

Testing

Test scripts are available to roll out new changes. The test scripts are not domain specific. The test script matches the production script functionality except:

1. There is no cache, meaning changes can be viewed immediately.
2. This script will function on your test site and should be used for testing purposes only.

Publishing the test scripts will not affect the live production scripts.

Production

Production scripts are for use in live websites. Fatest page load speed. Published changes will take up to 4 hours to show.

The script tags need to be placed as the first element in the of the site. It is important that the OneTrust script is placed before other scripts on the site to ensure users have a chance to consider their cookie preferences before cookies are potentially dropped on their machines.

Scripts implemented in root domains are also applied to subsequent subdomains and paths. Scripts implemented on subdomains are only applied to subdomains.

In order to push changes to production, click Publish Production Scripts and note any changes to the script as you may have to re-copy and re-implement the script in the of the site.

Script Version

Click Publish Test. Here you can choose which version of the script to publish. You will also be alerted to which features may or may not be compatible with a script version including the field name, old value, and new value. Click Confirm.

Publication Settings

Here you can confirm the publication settings of the script. Note: enabling or disabling some of these settings may change the embed script and would have to be re-implemented on the site.

1. Publish individual langauges: when toggle is off, all languages will be published
2. Do you require users to re-consent? Switching to IAB TCF 2.0 requires that your users re-consent, as preferences have changed. TCF 2.0 is not backwards compatible with TCF 1.0
3. Prevent fetching banner: When toggle is on, the banner template HTML and CSS will not be fetched from server as the otSDKStub.js loads
4. Prevent fetching preference center: When toggle is on, the preference center template HTML and CSS will not be fetched from server as the otSDKStub.js loads
5. Enable automatic blocking of cookies: If enabled, cookies will automatically be blocked until user has consented. Auto-blocking will block scripts that drop cookies categorized outside of strictly necessary on page load automatically
6. Enable language detection on scripts: if the language cannot be determined, the templates default language will be used (options: determine the language from the site visitor's browser settings or determine the language from HTML page)

Click Publish Test Scripts. Implement the script into the HTML of your staging site.

Do Not Sell & Cookie Setting Button

This will display either Do Not Sell My Data button or Cookie Settings button based on where the site visitors come from according to the geolocation rule group associated with the domain. The script has a class that can be customized through CSS.

Cookie List Script

These two methods initialize the OneTrust Publisher SDK. The initializeOneTrustPublishersSDK method fetches all of the resources configured in geolocation rules, templates, and vendors. The loadPreferenceCenter method is used to load the banner or preference center. By passing in true, the preference center will always load. By passing in false, the banner will be displayed for initial consent and re-consent.