Privacy Risk Remediation Guide

This guide provides actionable remediation steps for addressing privacy risks identified during website assessments. These remediation steps are designed to help organizations fix privacy compliance issues and reduce their risk exposure.

Who Should Use This Guide:

• Insurance Partners: Use this guide to help clients understand how to address critical privacy risks identified in assessments
• Website Owners: Follow these steps to remediate privacy findings and improve compliance
• Privacy Teams: Reference this guide when implementing privacy controls and consent management

How to Use This Guide:

1. Identify the reason code from your privacy assessment report
2. Find the corresponding section in this guide
3. Follow the remediation steps in order
4. Test your implementation to verify the issue is resolved
5. Re-run assessments to confirm remediation

---

Table of Contents

• Quick Reference by Severity
• Critical Risks
• High Risks
• Medium Risks
• Testing Your Remediation
• Additional Resources

---

Quick Reference by Severity

Severity	Description
Critical	Immediate action required. These risks pose significant privacy and compliance violations.
High	Address promptly. These risks can lead to compliance issues and user privacy concerns.

Quick Reference: All Reason Codes

Click to expand full list of reason codes

Reason Code	Severity	Description
gpc-not-functioning	CRITICAL	Global Privacy Control (GPC) signal is not being properly respected, allowing tracking technologies to load despite user opt-out preferences
critical-geo-risk	CRITICAL	Third-party requests are being made to domains hosted in geographic locations that pose privacy or security risks, particularly to countries with data protection concerns
domain-hijacking	CRITICAL	Domains that have changed ownership to potentially malicious actors, posing security and privacy risks to users
vppa-social-tracker	CRITICAL	Social media tracking technologies are present on pages containing video content, potentially violating the Video Privacy Protection Act (VPPA) by sharing video-related URLs
meta-pixel-critical	CRITICAL	Meta Pixel (Facebook Pixel) is present on the website, which can pose privacy risks, especially for healthcare organizations subject to HIPAA
social-media-domain-critical	CRITICAL	Social media tracking domains are present on the website, which can pose privacy risks, especially for healthcare organizations
excessive-trackers	CRITICAL	Pages contain an excessive number of third-party tracking technologies, which can impact user privacy and website performance
data-brokers	CRITICAL	Data broker tracking technologies are present on the website, which collect and sell user data to third parties
form-data-sent-to-third-party	CRITICAL	Form data (such as email addresses, phone numbers, names, or other information entered into form fields) is being transmitted to third-party domains. This detection occurs by filling form fields with test data and monitoring request payloads to identify where form data is sent.
malware_domains	CRITICAL	Third-party domains identified as malware-related or flagged by security services, posing security and privacy risks
sensitive_data_to_bad_geo	CRITICAL	Form data or sensitive information is being transmitted to third-party domains hosted in undesirable geographic locations (e.g., North Korea, China) that pose privacy and security risks
missing_gpc	CRITICAL	No third-party scripts on the website are reading the Global Privacy Control (GPC) signal, indicating GPC is not implemented or enabled
tiktok_pixel_critical	CRITICAL	TikTok Pixel is present on the website, which poses significant privacy risks due to TikTok's aggressive user reidentification practices, especially for healthcare organizations subject to HIPAA
tracker_location_data_broker	CRITICAL	Location data broker tracking technologies are present on the website, which collect and sell precise geolocation data to third parties
gpc_not_effective_on_initial_load	CRITICAL	Global Privacy Control (GPC) signal is not being respected on the initial page load, requiring a page reload before GPC becomes effective, which means tracking technologies load before GPC can be enforced
consent-banner-missing	HIGH	Pages that do not display a consent banner or privacy notice to users
trackers-present-with-gpc	HIGH	Tracking technologies are loading even when Global Privacy Control signal is enabled, indicating GPC is not being properly enforced
session-replay-domains	HIGH	Session replay tools are present that record user interactions, mouse movements, and screen activity, which can capture sensitive information
chatbot-with-session-replay	HIGH	Chatbot tools are present that include session replay capabilities, which can record user interactions and sensitive information shared during chat sessions
page-url-shared-with-third-party	HIGH	Page URLs are being shared with third-party domains, which can expose sensitive information embedded in URLs such as search terms, user identifiers, or personal data
third-party-iframe-tracker-domains	HIGH	Third-party tracking technologies are being loaded via iframes, which can bypass some privacy controls and consent mechanisms
fingerprint_weighting_41_plus	HIGH	Third-party scripts detected performing excessive browser fingerprinting by calling numerous DOM methods used to identify and track users across websites
bad_ssl_domains	HIGH	Third-party domains with SSL certificate issues (expired, invalid, self-signed, or misconfigured certificates) that trigger browser security warnings
chatbot-domains	MEDIUM	Chatbot tools are present on the website, which may collect user interactions and personal information
social-media-domain	MEDIUM	Social media tracking domains are present on the website
cookies	MEDIUM	Excessive cookie usage, particularly third-party cookies, which can impact user privacy
third-party-trackers-inventory	MEDIUM	A comprehensive inventory of third-party tracking domains present on the website
third-party-iframe-domains	MEDIUM	Third-party content (not classified as trackers) is being loaded via iframes
young-domains	MEDIUM	Third-party domains that were registered between 31 and 180 days ago, which may indicate new or potentially risky services
1st_party_cookies	MEDIUM	Excessive number of first-party cookies, which can be read by any third-party script and may contain sensitive information accessible across third parties

---

Critical Risks

🚨 Immediate Action Required

These critical risks require immediate attention.

GPC Not Functioning

Reason Code: gpc-not-functioning

Description: Global Privacy Control (GPC) signal is not being properly respected, allowing tracking technologies to load despite user opt-out preferences

Remediation Steps:

Step 1: Verify CMP Supports GPC and Enable Signal Reading

First, verify that your consent management platform (CMP) supports Global Privacy Control (GPC). Most modern CMPs support GPC, but it must be explicitly enabled in the configuration. If your CMP doesn't support GPC, consider upgrading or switching to one that does.

Verification and Configuration Steps:

1. Check your CMP documentation or contact support to confirm GPC support
2. Access your CMP administration panel
3. Navigate to privacy signal settings (may be labeled as "Privacy Signals", "GPC", "Do Not Sell", or similar)
4. Enable "Global Privacy Control" or "GPC Signal" option
5. Configure the CMP to treat GPC signal as an opt-out request (same as explicit opt-out)
6. Save and publish the configuration changes
7. Test GPC detection using browser extensions or developer tools

Step 2: Verify CMP Rules Are Correctly Configured

Even if GPC signal reading is enabled, incorrect rules in your consent manager can prevent proper enforcement. The most common issue is that tracking technologies are not properly categorized, or the CMP rules don't actually block them when GPC is detected. Review and update your CMP rules to ensure all tracking technologies are properly categorized and blocked when GPC is detected.

Rule Configuration Checklist:

• Audit all third-party tracking domains in your CMP configuration
• Ensure each domain is properly categorized (essential, functional, analytics, marketing, advertising)
• Verify that "strictly necessary" or "essential" category only includes truly essential cookies (e.g., authentication, security)
• Check that marketing, analytics, and advertising tags are set to require consent
• Verify that GPC signal triggers the same blocking behavior as explicit opt-out
• Review vendor-specific rules (e.g., Google Analytics, Meta Pixel, LinkedIn Insight Tag) to ensure they respect GPC
• Test each tracker category individually to confirm blocking behavior
• Check if your CMP has separate GPC-specific rules that need configuration

Step 3: Implement Server-Side GPC Detection

For comprehensive GPC support, implement server-side detection of the Sec-GPC header. This ensures GPC is respected even for server-side tracking and analytics.

Implementation approach:

• Configure your web server to read the Sec-GPC HTTP header
• Modify server-side tracking scripts to check for GPC signal
• Ensure server-side analytics respect GPC opt-out
• Document GPC handling in your privacy policy

Step 4: Test GPC Signal Respect

Regularly test that GPC signal is being properly detected and respected. Use browser extensions that send GPC signals or manually set the Sec-GPC header to verify behavior.

Testing methods:

• Use browser extensions like Privacy Badger or DuckDuckGo Privacy Essentials
• Manually set Sec-GPC: 1 header using browser developer tools
• Verify network requests show no tracking when GPC is enabled
• Test across different browsers (Chrome, Firefox, Safari, Edge)
• Verify GPC respect persists across page navigation

Step 5: Update Privacy Policy to Document GPC Support

Document your GPC support in your privacy policy and ensure users understand how to enable GPC in their browsers or through browser extensions.

Privacy policy updates should include:

• Explanation of what GPC is
• How users can enable GPC
• Confirmation that your site respects GPC signals
• Instructions for users who want to opt-out via GPC

Critical Geo Risk

Reason Code: critical-geo-risk

Description: Third-party requests are being made to domains hosted in geographic locations that pose privacy or security risks, particularly to countries with data protection concerns

Remediation Steps:

Step 1: Remove Third-Party Services from Risky Geographic Locations

The most effective remediation is to remove third-party services that route data through risky geographic locations. Identify alternative vendors or services that operate from more privacy-friendly jurisdictions. This is often the only viable option when vendors cannot or will not change their geographic routing.

Removal process:

• Identify all third-party domains associated with risky geographic locations
• Evaluate whether these services are essential to your website functionality
• Document the functionality provided by each risky service
• Research alternative vendors that operate from privacy-friendly jurisdictions (EU, US, Canada, etc.)
• Evaluate alternatives for functionality, cost, and privacy practices
• Plan migration timeline and test alternative solutions before removing originals
• Remove risky third-party scripts and verify removal using browser developer tools
• Monitor for any re-introduction of risky geographic connections

Step 2: Configure CDN and Hosting to Use Privacy-Friendly Regions

If the third-party service is essential and cannot be removed, work with the vendor to configure their service to route data through privacy-friendly geographic regions. Many CDN and cloud providers offer region selection options, but this may not be available for all services.

Configuration steps:

• Contact third-party vendor to discuss geographic routing options
• Verify that the vendor offers region selection or geographic routing controls
• Request data processing to occur in privacy-friendly regions (e.g., EU, US, Canada)
• Review vendor's data processing agreements and geographic commitments
• Update vendor contracts to specify geographic restrictions and data residency requirements
• Configure vendor dashboard or API settings to select approved regions
• Monitor network requests using browser developer tools to verify routing changes
• Test from different geographic locations to confirm data routing
• Document geographic configuration for compliance audits

Step 3: Implement Data Residency Controls

For organizations subject to data residency requirements, implement technical controls that prevent data from being sent to unauthorized geographic locations. This may involve proxy services or regional gateways.

Technical controls:

• Use regional proxy services to route traffic through approved regions
• Implement Content Security Policy (CSP) to restrict third-party connections
• Use DNS filtering to block connections to risky geographic locations
• Deploy web application firewall (WAF) rules to block risky domains
• Monitor and log all third-party connections for compliance auditing

Step 4: Review and Update Data Processing Agreements

Ensure all data processing agreements with third-party vendors explicitly specify geographic restrictions and data residency requirements. Legal agreements should complement technical controls.

Agreement review checklist:

• Verify geographic data processing restrictions are specified
• Ensure vendor commits to processing data only in approved regions
• Include audit rights to verify geographic compliance
• Specify consequences for non-compliance
• Update agreements as new vendors are onboarded

Domain Hijacking

Reason Code: domain-hijacking

Description: Domains that have changed ownership to potentially malicious actors, posing security and privacy risks to users

Remediation Steps:

Step 1: Immediately Remove Hijacked Domains

Remove all references to hijacked domains from your website immediately. This includes script tags, iframe embeds, API endpoints, and any other references to the compromised domain.

Removal process:

• Search codebase for all references to the hijacked domain
• Remove script tags, iframe sources, and API endpoints
• Update CDN configurations and external resource references
• Remove from tag manager configurations
• Verify removal using browser developer tools and network monitoring

Step 2: Replace with Trusted Alternatives

If the hijacked domain was providing essential functionality, replace it with a trusted alternative. Research and select vendors with strong security practices and domain ownership stability.

Replacement considerations:

• Identify the functionality provided by the hijacked domain
• Research trusted alternatives with similar capabilities
• Evaluate security and privacy practices of alternatives
• Test replacement solutions before full deployment
• Update documentation and vendor lists

Step 3: Implement Domain Monitoring and Validation

Establish processes to monitor third-party domains for ownership changes and security issues. Use domain reputation services and security monitoring tools to detect hijacking early.

Monitoring Strategies:

• Subscribe to domain reputation monitoring services
• Implement automated checks for domain ownership changes
• Use security scanning tools to detect malicious domains
• Set up alerts for domain status changes
• Regularly review third-party vendor security postures

Step 4: Use Subresource Integrity (SRI) for External Resources

Implement Subresource Integrity (SRI) hashes for external scripts and resources. While this won't prevent hijacking, it will prevent compromised resources from executing on your site.

SRI Implementation:

<script src="https://example.com/script.js"
  integrity="sha384-..."
  crossorigin="anonymous">&lt;/script&gt;

• Generate SRI hashes for all external scripts
• Add integrity and crossorigin attributes
• Update hashes when scripts are updated
• Monitor for integrity check failures

Step 5: Review Third-Party Vendor Security Practices

Establish a vendor security review process that includes domain ownership verification, security posture assessment, and ongoing monitoring of third-party dependencies.

Vendor review process:

• Verify domain ownership and registration details
• Check vendor security certifications and compliance
• Review vendor's incident response history
• Establish vendor security assessment criteria
• Create approved vendor list with regular review cycles

VPPA Social Tracker

Reason Code: vppa-social-tracker

Description: Social media tracking technologies are present on pages containing video content, potentially violating the Video Privacy Protection Act (VPPA) by sharing video-related URLs

Remediation Steps:

Step 1: Remove Video-Related Keywords from URLs

Modify your URL structure to remove video-related keywords (e.g., 'video', 'watch', 'replay', 'stream') that could be interpreted as video content identifiers. This is often the simplest and most effective remediation.

URL Restructuring Examples:

• Change: /videos/watch-content-123 → /content/media-123
• Change: /video/replay-session → /session/archive
• Change: /watch?v=abc123 → /media?id=abc123
• Use generic terms like 'content', 'media', 'archive' instead of video-specific terms
• Update internal links and redirects accordingly

Step 2: Remove Social Trackers from Video Pages

Exclude social media tracking technologies from pages that contain video content. This prevents social trackers from capturing video-related URLs in their standard telemetry. This is often easier to implement than URL restructuring and provides immediate VPPA compliance.

Implementation approach:

• Identify all pages containing video content (native video players, YouTube embeds, Vimeo, etc.)
• If using a tag manager, configure page-level conditions to exclude social trackers on video pages
• For direct script implementations, add conditional checks to prevent social tracker loading on video pages
• Use URL patterns or page identifiers to identify video pages
• Consider using separate page templates or layouts for video content
• Test using browser developer tools to verify social trackers are not loading on video pages
• Monitor network requests to confirm no social tracker domains are contacted on video pages

Step 3: Implement URL Sanitization for Social Trackers

If social trackers must remain on video pages, implement URL sanitization that removes or masks video-related information before it's sent to social media platforms.

URL Sanitization Strategy:

• Intercept social tracker initialization
• Modify page URL or referrer before sending to social platforms
• Remove video-related query parameters
• Use generic page identifiers instead of descriptive URLs
• Implement server-side URL rewriting for social tracker endpoints

Step 4: Use Consent Management to Control Social Trackers

Configure your consent management platform to require explicit consent for social media trackers, and ensure users can opt-out. When users opt-out, social trackers should not load, eliminating VPPA risk.

CMP configuration:

• Categorize social media trackers as 'marketing' or 'advertising'
• Require explicit consent before loading social trackers
• Ensure opt-out prevents social tracker initialization
• Test consent flow to verify social trackers respect opt-out
• Document consent requirements in privacy policy

Step 5: Separate Video Content into Dedicated Subdomain

Consider hosting video content on a separate subdomain (e.g., video.example.com) and exclude social trackers from that subdomain entirely. This creates a clear separation between video content and tracking technologies.

Subdomain separation:

• Create dedicated subdomain for video content
• Configure subdomain to exclude social trackers
• Update video embeds to use subdomain URLs
• Implement cross-domain tracking restrictions
• Update privacy policy to document subdomain usage

Meta Pixel Critical

Reason Code: meta-pixel-critical

Description: Meta Pixel (Facebook Pixel) is present on the website, which can pose privacy risks, especially for healthcare organizations subject to HIPAA

Remediation Steps:

Step 1: Remove Meta Pixel from Healthcare Sites

For healthcare organizations, the best practice is to completely remove Meta Pixel from the website. Meta Pixel's data collection practices may conflict with HIPAA requirements and patient privacy expectations.

Removal process:

• Identify all Meta Pixel implementations (direct scripts, tag manager, etc.)
• Remove Meta Pixel script tags from page templates
• Remove Meta Pixel from tag manager configurations
• Remove Meta Pixel event tracking code from forms and pages
• Verify removal using browser developer tools and network monitoring

Step 2: Configure Meta Pixel in Privacy-Focused Mode

If Meta Pixel must be retained for non-healthcare use cases, configure it in the most privacy-focused manner possible. Disable features that send PII and use server-side alternatives where available.

Privacy-Focused Configuration:

• Disable automatic event tracking (PageView, ViewContent, etc.)
• Use Meta's Conversions API (server-side) for conversions instead of client-side pixel when possible
• Configure pixel to not track granular URLs (use generic page identifiers like 'product-page' instead of full URLs)
• Disable Advanced Matching features that send PII (email, phone, name)
• If using Conversions API, hash and anonymize any data before sending to Meta
• Limit pixel to specific, non-sensitive pages only (exclude forms, checkout, account pages)
• Configure pixel to respect consent signals (see Step 3)
• Review Meta Pixel documentation for additional privacy settings

Step 3: Gate Meta Pixel Behind Consent Management - Block Script Entirely

Ensure Meta Pixel script does NOT load at all when users opt out. Configure your consent management platform and tag manager to completely block Meta Pixel script execution when users opt out. Do not rely on Meta Pixel privacy settings - block the script entirely.

Consent gating (block script entirely):

• Categorize Meta Pixel as 'marketing' or 'advertising' in CMP
• If using tag manager (recommended), configure it to block Meta Pixel script from loading when users opt out
• Configure CMP to signal tag manager to prevent Meta Pixel loading
• Ensure opt-out immediately prevents Meta Pixel script from executing (not just disabling tracking)
• Test using browser Network tab to verify Meta Pixel script does NOT load when opted out
• Verify complete absence of Meta Pixel requests, not just privacy settings
• Test consent flow regularly to verify Meta Pixel is blocked
• Document consent requirements in privacy policy

Step 4: Use Server-Side Tracking Alternative

Consider replacing client-side Meta Pixel with server-side tracking using Meta's Conversions API. Server-side tracking provides better privacy controls and reduces client-side data collection.

Server-side implementation:

• Set up Meta Conversions API endpoint
• Send conversion events from server instead of browser
• Hash and anonymize any data before sending to Meta
• Implement proper access controls and authentication
• Monitor server-side API usage and errors

Step 5: Review and Update Privacy Policy

If Meta Pixel is retained, ensure your privacy policy clearly discloses Meta Pixel usage, the data collected, how it's used, and user rights regarding Meta Pixel data.

Privacy policy updates:

• Disclose Meta Pixel presence and purpose
• Explain what data Meta Pixel collects
• Describe how data is used by Meta
• Provide instructions for opting out
• Include links to Meta's privacy policy and ad preferences

Social Media Domain Critical

Reason Code: social-media-domain-critical

Description: Social media tracking domains are present on the website, which can pose privacy risks, especially for healthcare organizations

Remediation Steps:

Step 1: Remove Social Media Trackers from Healthcare Sites

For healthcare organizations, remove social media tracking domains entirely. Social media trackers collect extensive user data that may conflict with HIPAA requirements and patient privacy expectations.

Removal process:

• Identify all social media tracker implementations (LinkedIn, Twitter, Facebook, etc.)
• Remove social media script tags and pixels
• Remove social media trackers from tag manager
• Remove social sharing widgets that include tracking
• Verify removal using browser developer tools

Step 2: Gate Social Media Trackers Behind Consent - Block Scripts Entirely

For non-healthcare sites, ensure social media tracker scripts do NOT load at all when users opt out. Use a tag manager as the enforcement layer to completely block script execution. Configure your consent management platform to signal the tag manager to prevent social tracker loading until marketing/advertising consent is granted.

Consent configuration (block scripts entirely):

• Categorize all social media domains as 'marketing' or 'advertising' in CMP
• If using tag manager (recommended), configure it to block social tracker scripts from loading when users opt out
• Configure CMP to require explicit consent and signal tag manager
• Ensure opt-out immediately prevents social tracker scripts from executing (complete blocking, not just privacy settings)
• Test using browser Network tab to verify social tracker scripts do NOT load when opted out
• Verify complete absence of social tracker requests
• Test consent flow across all social media platforms regularly
• Document consent requirements clearly

Step 3: Use Privacy-Focused Social Sharing Alternatives

Replace social sharing widgets that include tracking with privacy-focused alternatives. Use static share links or server-side sharing mechanisms that don't load third-party tracking scripts.

Alternative approaches:

• Replace social widgets with static share URLs (mailto:, custom share endpoints)
• Use server-side sharing mechanisms
• Implement custom share buttons without third-party scripts
• Consider removing social sharing functionality if not essential
• Test alternatives to ensure functionality is maintained

Step 4: Limit Social Trackers to Specific Pages

If social media trackers are necessary for marketing purposes, limit them to specific, non-sensitive pages only. Exclude social trackers from pages containing sensitive information, forms, or healthcare content.

Page-level restrictions:

• Identify pages where social trackers are acceptable (e.g., marketing pages, blog posts)
• If using a tag manager, configure page-level conditions to exclude social trackers from sensitive pages
• For direct script implementations, add conditional checks based on page URL or page type
• Exclude social trackers from sensitive pages (forms, checkout, account pages, healthcare content, etc.)
• Use URL patterns or page identifiers to control social tracker loading
• Test to verify social trackers don't load on excluded pages
• Regularly audit page-level configurations as new pages are added

Excessive Trackers

Reason Code: excessive-trackers

Description: Pages contain an excessive number of third-party tracking technologies, which can impact user privacy and website performance

Remediation Steps:

Step 1: Conduct Tracker Audit and Rationalization

Perform a comprehensive audit of all third-party trackers to identify which are essential versus nice-to-have. Remove redundant trackers and consolidate functionality where possible.

Audit Process:

1. List all third-party tracking domains
2. Document the purpose and business justification for each tracker
3. Identify redundant trackers (e.g., multiple analytics tools)
4. Evaluate whether functionality can be consolidated
5. Create removal plan for non-essential trackers
6. Obtain stakeholder approval for removals
7. Execute removal plan with testing at each step

Step 2: Implement Consent Management - Block Scripts Entirely When Opted Out

Ensure all non-essential trackers are properly gated behind consent management. Use a tag manager as the enforcement layer to completely block scripts from loading when users opt out. Do not rely on privacy settings within scripts - block scripts entirely. Regularly test to verify scripts are actually blocked.

Consent management implementation:

• Categorize all trackers (essential, analytics, marketing, etc.) in CMP
• Deploy all trackers through tag manager (not directly in templates)
• Configure tag manager to receive consent signals from CMP
• Configure tag manager to COMPLETELY BLOCK script loading for non-essential trackers when users opt out
• Ensure opt-out prevents all non-essential tracker scripts from executing (not just disabling tracking)
• Test consent flow regularly using browser Network tab to verify scripts do NOT load when opted out
• Verify complete absence of tracking requests, not just privacy settings
• Monitor consent rates and adjust categorization as needed
• Schedule monthly testing to ensure consent manager continues to work as new tags are added

Step 3: Consider Using a Tag Manager for Centralized Control

If you're managing many trackers, consider deploying tracking technologies through a tag manager (such as Google Tag Manager, Adobe Launch, Tealium, or similar) rather than hardcoding scripts. Tag managers provide centralized control, easier management, and better consent enforcement capabilities.

Tag manager benefits:

• Centralized tracker management and configuration in one interface

• Easier consent enforcement through tag manager consent mode features

• Simplified testing and debugging with preview/debug modes

• Better control over tag firing conditions and triggers

• Easier to add/remove trackers without code deployments

• Built-in consent integration with many CMPs

• Note: Tag managers are optional. If you prefer direct script implementations, ensure you implement proper consent gating manually.

Step 4: Implement Lazy Loading and Conditional Loading

Use lazy loading and conditional loading strategies to ensure trackers only load when necessary. This reduces the number of trackers loaded on each page view.

Loading strategies:

• Load trackers only on specific pages where needed
• Use event-based loading (e.g., load analytics only after user interaction)
• Implement scroll-based loading for below-the-fold trackers
• Use intersection observers for viewport-based loading
• Defer non-critical tracker loading until after page load

Step 5: Establish Tracker Approval Process

Create a formal process for approving new trackers before they're added to the website. This prevents tracker sprawl and ensures all trackers have clear business justification.

Approval process should include:

• Business justification for the tracker
• Privacy impact assessment
• Consent management requirements
• Data retention and sharing policies
• Removal criteria and sunset dates
• Regular review cycle for existing trackers

Data Brokers

Reason Code: data-brokers

Description: Data broker tracking technologies are present on the website, which collect and sell user data to third parties

Remediation Steps:

Step 1: Remove Data Broker Trackers

The most effective remediation is to completely remove data broker trackers from your website. Data brokers collect extensive user data and sell it to third parties, which conflicts with user privacy expectations and may violate privacy regulations.

Removal process:

• Identify all data broker domains (common examples: BlueKai/Oracle, LiveRamp, Acxiom, Epsilon, Experian, Equifax)
• Search your codebase for references to data broker domains
• Remove data broker scripts and pixels from page templates
• If using a tag manager, remove data broker configurations
• Remove data broker references from vendor lists and documentation
• Verify removal using browser developer tools network tab
• Test across different pages to ensure complete removal
• Monitor for any re-introduction of data broker trackers
• Update vendor lists to prevent future data broker additions

Step 2: Review Vendor Contracts and Data Sharing Agreements

Review all vendor contracts to identify any data sharing arrangements with data brokers. Terminate or modify agreements that allow data broker access to user data.

Contract review:

• Audit all third-party vendor agreements
• Identify any data sharing clauses with data brokers
• Review data processing addendums (DPAs)
• Terminate or modify agreements to prohibit data broker sharing
• Update vendor onboarding process to prevent future data broker agreements

Step 3: Implement Consent Management for Remaining Data Brokers

If data broker trackers cannot be immediately removed, ensure they are properly gated behind consent management and require explicit user consent before loading.

Consent configuration:

• Categorize data broker trackers as 'marketing' or 'advertising'
• Require explicit opt-in consent (not pre-checked)
• Ensure opt-out immediately stops data broker tracking
• Clearly disclose data broker usage in privacy policy
• Provide users with information about data broker opt-out options

Step 4: Update Privacy Policy to Disclose Data Broker Usage

If data brokers are present, your privacy policy must clearly disclose their presence, what data they collect, how it's used, and provide users with opt-out mechanisms.

Privacy policy requirements:

• List all data broker partners by name
• Explain what data is collected and shared
• Describe how data brokers use the information
• Provide links to data broker opt-out pages
• Explain user rights regarding data broker data
• Update policy whenever data broker relationships change

Step 5: Provide Users with Data Broker Opt-Out Resources

Help users exercise their rights by providing information and links to data broker opt-out mechanisms. Many data brokers offer opt-out pages, though the process can be complex.

User resources:

• Create a dedicated page explaining data broker opt-out
• Provide direct links to major data broker opt-out pages
• Explain the opt-out process and limitations
• Consider providing a centralized opt-out tool if available
• Regularly update opt-out resources as data broker landscape changes

Form Data Sent to Third Party

Reason Code: form-data-sent-to-third-party

Description: Form data (such as email addresses, phone numbers, names, or other information entered into form fields) is being transmitted to third-party domains. This detection occurs by filling form fields with test data and monitoring request payloads to identify where form data is sent.

Remediation Steps:

Step 1: Verify Third-Party Domain Legitimacy and Purpose

First, identify which third-party domain is receiving form data and verify whether this is expected and legitimate. Many websites use form providers (such as HubSpot, Salesforce, Marketo, Typeform, or similar) where form data transmission is intentional and necessary for form functionality.

Verification process:

• Identify the third-party domain receiving form data from network requests
• Determine if this is a known form provider or form management service
• Check your website's form implementation to confirm if this third party is intentionally integrated
• Review form provider documentation to understand expected data transmission
• Verify the third-party domain matches your form provider's official domains
• Document which forms send data to which third parties and why

Step 2: Assess Industry and Regulatory Compliance Requirements

Evaluate whether sending form data to third parties is permitted under applicable laws and regulations for your industry. Healthcare organizations subject to HIPAA, financial institutions, and other regulated industries may have restrictions on sharing form data with third parties.

Compliance Assessment:

For Healthcare Organizations (HIPAA):

• Sending form data containing protected health information (PHI) to third parties typically requires a Business Associate Agreement (BAA)
• Verify the form provider has signed a BAA and is HIPAA-compliant
• If no BAA exists, sending PHI to third parties may violate HIPAA
• Consider using HIPAA-compliant form providers or processing forms server-side

For Financial Institutions:

• Review GLBA (Gramm-Leach-Bliley Act) requirements for sharing customer information
• Verify third-party compliance with financial regulations
• Ensure proper data protection agreements are in place

For Other Industries:

• Review GDPR requirements if processing EU resident data
• Review CCPA/CPRA requirements if processing California resident data
• Check industry-specific regulations (FERPA for education, etc.)
• Consult with legal/compliance teams to determine permissibility

Step 3: Review and Establish Data Processing Agreements

If form data transmission to third parties is legitimate and compliant, ensure proper legal agreements are in place. All third parties receiving form data should have appropriate data processing agreements (DPAs) or business associate agreements (BAAs) that define data handling responsibilities.

Agreement requirements:

• Verify that data processing agreements (DPAs) or business associate agreements (BAAs) are in place
• Review agreements to ensure they cover form data transmission
• Confirm third-party vendor security and compliance certifications
• Ensure agreements specify data protection requirements and breach notification procedures
• Verify agreements include audit rights and data deletion requirements
• Update agreements if they don't adequately cover form data handling
• Document all third-party form data recipients and their agreement status

Step 4: Remove Form Data Transmission if Not Legitimate or Compliant

If the third-party domain is not a legitimate form provider, or if sending form data violates regulatory requirements, remove the form data transmission. This may require changing form implementation, using alternative form providers, or processing forms server-side.

Removal process:

• Identify the source of form data transmission (form provider script, custom form handler, etc.)
• If using a form provider, evaluate switching to a compliant alternative or server-side processing
• For custom forms, modify form submission handlers to prevent client-side transmission to third parties
• Process forms server-side and send data to third parties only if necessary and compliant
• Remove any unauthorized third-party scripts that intercept form submissions
• Test form functionality after changes to ensure forms still work correctly
• Verify using browser developer tools that form data is no longer sent to unauthorized third parties

Step 5: Update Privacy Policy to Disclose Form Data Sharing

If form data is legitimately sent to third parties, clearly disclose this in your privacy policy. Users should understand what form data is collected, where it's sent, and how it's used.

Privacy policy disclosure requirements:

• Clearly state that form data may be sent to third-party form providers
• List the third-party form providers or categories of providers used
• Explain what form data is collected and transmitted
• Describe how third parties use the form data
• Specify data retention and deletion policies
• Provide information about user rights regarding their form data
• Include instructions for users who want to opt-out or request data deletion
• Update privacy policy whenever form providers or data sharing practices change

Step 6: Implement Consent for Form Data Collection and Sharing

Ensure users provide appropriate consent before form data is collected and shared with third parties. This is especially important for non-essential forms or when form data is used for marketing purposes.

Consent implementation:

• Obtain explicit consent before collecting form data, especially for marketing or non-essential forms
• Clearly disclose that form data will be shared with third parties before submission
• Provide granular consent options where possible (e.g., consent for form submission vs. marketing use)
• Ensure consent is obtained before form data is transmitted to third parties
• Provide easy mechanism for users to withdraw consent
• Document consent and make consent records easily accessible
• Consider using consent management platforms to track form data consent

Malware Domains

Reason Code: malware_domains

Description: Third-party domains identified as malware-related or flagged by security services, posing security and privacy risks

Remediation Steps:

Step 1: Immediately Remove Malware Domains

Remove all references to malware domains from your website immediately. These domains pose security risks and have no legitimate place on your website.

Removal process:

• Search codebase for all references to the malware domain
• Remove script tags, iframe sources, API endpoints, and image sources
• Remove from tag manager configurations
• Remove from CDN configurations and external resource references
• Check for hardcoded URLs in JavaScript, CSS, and HTML templates
• Verify removal using browser developer tools network tab
• Test across different pages to ensure complete removal
• Monitor for any re-introduction of malware domains

Step 2: Investigate How Malware Domain Was Added

Conduct a thorough investigation to determine how the malware domain was introduced to your website. This helps prevent future incidents and identifies potential security vulnerabilities.

Investigation steps:

• Review git commit history to identify when domain was added
• Check if domain was added through a compromised third-party script or library
• Review tag manager change logs and user access logs
• Check for unauthorized access to website administration panels
• Review third-party vendor relationships that may have introduced the domain
• Examine if domain was added through a supply chain attack
• Document investigation findings and remediation actions
• Update security procedures based on investigation results

Step 3: Replace with Trusted Alternatives if Functionality Was Provided

If the malware domain was providing legitimate functionality, replace it with a trusted, reputable alternative. Research vendors with strong security practices and verified legitimacy.

Replacement process:

• Identify the functionality that the malware domain was providing
• Research trusted alternatives with similar capabilities
• Verify vendor legitimacy and security practices
• Check vendor security certifications and compliance
• Test replacement solution before full deployment
• Update documentation and vendor lists
• Monitor replacement solution for security issues

Step 4: Implement Domain Monitoring and Validation

Establish processes to monitor third-party domains for security issues and malware associations. Use security services and domain reputation tools to detect compromised domains early.

Monitoring Strategies:

• Subscribe to domain reputation monitoring services (e.g., VirusTotal, URLVoid)
• Implement automated checks for domain security status
• Use security scanning tools to detect malicious domains
• Set up alerts for domain status changes and security flags
• Regularly review third-party vendor security postures
• Monitor for domain ownership changes that may indicate compromise
• Integrate domain validation into vendor onboarding process

Step 5: Review and Strengthen Third-Party Vendor Security Practices

Establish a vendor security review process that includes domain validation, security posture assessment, and ongoing monitoring of third-party dependencies.

Vendor security review:

• Verify domain ownership and registration details for all third-party vendors
• Check vendor security certifications and compliance status
• Review vendor's incident response history and security practices
• Establish vendor security assessment criteria
• Create approved vendor list with regular review cycles
• Require security documentation from vendors before onboarding
• Implement vendor security questionnaires and assessments

Sensitive Data to Bad Geo

Reason Code: sensitive_data_to_bad_geo

Description: Form data or sensitive information is being transmitted to third-party domains hosted in undesirable geographic locations (e.g., North Korea, China) that pose privacy and security risks

Remediation Steps:

Step 1: Verify Third-Party Domain and Data Transmission

First, verify that sensitive data is actually being sent to a third party in an undesirable geographic location. Use browser developer tools to confirm the destination and identify the source of the transmission.

Verification process:

• Use browser developer tools Network tab to identify form submissions
• Confirm the third-party domain receiving sensitive data
• Verify the geographic location of the third-party domain
• Identify which form fields or data are being transmitted
• Document the form or page where transmission occurs
• Check if transmission is expected or unexpected
• Verify if the third party is a known form provider or service

Step 2: Assess Whether Data Transmission Is Necessary

Evaluate whether sending sensitive data to a third party in an undesirable geographic location is absolutely necessary. In most cases, this is not necessary and poses significant privacy and security risks.

Assessment process:

• Evaluate whether the third-party service is essential
• Determine if alternative vendors in privacy-friendly jurisdictions are available
• Assess business justification for using this specific third party
• Review regulatory requirements that may prohibit data transmission to certain geographies
• Consider privacy and security risks versus business value
• Document assessment findings and decision rationale

Step 3: Remove or Replace Third-Party Service

If sending sensitive data to an undesirable geographic location is not necessary, remove the third-party service or replace it with an alternative in a privacy-friendly jurisdiction (e.g., EU, US, Canada).

Removal/replacement process:

• Identify all references to the problematic third-party domain
• Remove form submission handlers that send data to the third party
• Remove third-party scripts and API endpoints
• If using a form provider, evaluate switching to a provider in a privacy-friendly jurisdiction
• Research alternative vendors that operate from approved geographic locations
• Test replacement solution before full deployment
• Verify using browser developer tools that sensitive data is no longer sent to undesirable geographies
• Update documentation and vendor lists

Step 4: Implement Server-Side Form Processing

Process form submissions server-side instead of sending sensitive data directly to third parties from the browser. This gives you control over where data is sent and allows you to route data only to approved geographic locations.

Server-Side Processing Benefits:

• Complete control over data routing and geographic restrictions
• Ability to validate and sanitize data before transmission
• Can route data only to approved geographic locations
• Reduces client-side data exposure
• Better compliance with data residency requirements

Implementation:

• Modify form submission handlers to send data to your server
• Process form data server-side
• Route data to third parties only from server (if necessary)
• Implement geographic routing controls on server
• Validate and sanitize data before processing
• Log form submissions for compliance auditing

Step 5: Review and Update Data Processing Agreements

If data transmission to undesirable geographies must continue, ensure proper legal agreements are in place. However, this is generally not recommended due to privacy and security risks.

Agreement review (if transmission must continue):

• Review data processing agreements with third-party vendors
• Verify agreements specify geographic data processing locations
• Ensure agreements include data protection requirements
• Review vendor security practices and compliance
• Consider terminating agreements if geographic restrictions cannot be met
• Document all data transmission agreements and geographic restrictions
• Consult with legal/compliance teams about regulatory requirements

Step 6: Update Privacy Policy to Disclose Data Transmission

If sensitive data transmission to undesirable geographies continues, clearly disclose this in your privacy policy. However, disclosure alone does not mitigate the risk, and removal is strongly recommended.

Privacy policy disclosure (if transmission continues):

• Explicitly state that sensitive data is transmitted to third parties in specific geographic locations
• List the third-party vendors and their geographic locations
• Explain what sensitive data is transmitted
• Describe how data is used by third parties
• Explain privacy and security risks
• Provide information about user rights
• Include instructions for users who want to opt-out
• Note: Disclosure does not eliminate risk - removal is strongly recommended

Missing GPC

Reason Code: missing_gpc

Description: No third-party scripts on the website are reading the Global Privacy Control (GPC) signal, indicating GPC is not implemented or enabled

Remediation Steps:

Step 1: Enable GPC Signal Reading in Consent Management Platform

Enable Global Privacy Control (GPC) signal reading in your consent management platform. Most modern CMPs support GPC, but it must be explicitly enabled in the configuration.

CMP Configuration Steps:

1. Access your consent management platform administration panel
2. Navigate to privacy signal settings (may be labeled as "Privacy Signals", "GPC", "Do Not Sell", or similar)
3. Enable "Global Privacy Control" or "GPC Signal" option
4. Configure the CMP to treat GPC signal as an opt-out request (same as explicit opt-out)
5. Set GPC to apply to all non-essential tracking categories
6. Save and publish the configuration changes
7. Test GPC detection using browser extensions or developer tools
8. Verify that GPC signal is being read by checking browser console or network requests

Step 2: Verify CMP Categorization Rules Are Complete

Even if GPC signal reading is enabled, incomplete categorization rules can prevent proper enforcement. Ensure all third-party tracking domains are properly categorized so GPC can block them appropriately.

Rule Configuration Checklist:

• Audit all third-party tracking domains in your CMP configuration
• Ensure each domain is properly categorized (essential, functional, analytics, marketing, advertising)
• Verify that "strictly necessary" or "essential" category only includes truly essential cookies (e.g., authentication, security)
• Check that marketing, analytics, and advertising tags are set to require consent
• Verify that GPC signal triggers blocking for all non-essential categories
• Review vendor-specific rules (e.g., Google Analytics, Meta Pixel, LinkedIn Insight Tag) to ensure they respect GPC
• Test each tracker category individually to confirm blocking behavior when GPC is enabled
• Update categorization rules as new third parties are added

Step 3: Configure Tag Manager to Respect GPC Signal

If using a tag manager, configure it to read GPC signals and block scripts accordingly. Use tag manager consent mode features or custom variables to check for GPC before loading tags.

Tag Manager Configuration:

• Enable GPC signal detection in tag manager settings or consent mode
• Create consent state variables that check for GPC signal (navigator.globalPrivacyControl === true)
• Configure all non-essential tags to check GPC signal before loading
• Set up triggers that PREVENT tag execution when GPC is detected
• Use tag manager's built-in consent mode features if available (e.g., Google Tag Manager Consent Mode)
• Test tag manager configuration with GPC enabled to verify blocking
• Document tag manager GPC configuration for future reference

Step 4: Test GPC Signal Detection and Enforcement

Regularly test that GPC signal is being properly detected and that tracking scripts are completely blocked when GPC is enabled. Use browser extensions or developer tools to verify behavior.

Testing methods:

• Use browser extensions like Privacy Badger, DuckDuckGo Privacy Essentials, or similar that send GPC signals
• Manually set GPC signal using browser developer tools (navigator.globalPrivacyControl = true)
• Check browser console for GPC detection
• Use Network tab in browser developer tools to verify NO tracking requests are made when GPC is enabled
• Verify that tracking scripts do NOT load at all when GPC is enabled
• Test specific services (e.g., verify Google Analytics script does NOT load)
• Test across different browsers (Chrome, Firefox, Safari, Edge)
• Verify GPC respect persists across page navigation
• Compare behavior with explicit opt-out to ensure they match
• Document test results and schedule regular testing (monthly recommended)

Step 5: Update Privacy Policy to Document GPC Support

Document your GPC support in your privacy policy and ensure users understand how to enable GPC in their browsers or through browser extensions.

Privacy policy updates should include:

• Explanation of what Global Privacy Control (GPC) is
• Confirmation that your site respects GPC signals
• Instructions for users on how to enable GPC in their browsers
• Information about browser extensions that send GPC signals
• Explanation that GPC signal is treated as an opt-out request
• Instructions for users who want to opt-out via GPC
• Links to GPC resources and documentation

Step 6: Implement Server-Side GPC Detection

For comprehensive GPC support, implement server-side detection of the Sec-GPC HTTP header. This ensures GPC is respected even for server-side tracking and analytics.

Server-side implementation:

• Configure your web server to read the Sec-GPC HTTP header
• Modify server-side tracking scripts to check for GPC signal
• Ensure server-side analytics respect GPC opt-out
• Implement server-side consent state that includes GPC signal
• Document GPC handling in your privacy policy
• Test server-side GPC detection using browser developer tools

TikTok Pixel Critical

Reason Code: tiktok_pixel_critical

Description: TikTok Pixel is present on the website, which poses significant privacy risks due to TikTok's aggressive user reidentification practices, especially for healthcare organizations subject to HIPAA

Remediation Steps:

Step 1: Remove TikTok Pixel from Healthcare Sites

For healthcare organizations, completely remove TikTok Pixel from the website. TikTok's data collection and reidentification practices conflict with HIPAA requirements and patient privacy expectations.

Removal process:

• Identify all TikTok Pixel implementations (direct scripts, tag manager, etc.)
• Remove TikTok Pixel script tags from page templates
• Remove TikTok Pixel from tag manager configurations
• Remove TikTok Pixel event tracking code from forms and pages
• Search codebase for TikTok Pixel references (tiktok.com, byteoversea.com domains)
• Verify removal using browser developer tools and network monitoring
• Test across different pages to ensure complete removal
• Monitor for any re-introduction of TikTok Pixel

Step 2: Assess TikTok Pixel Risk for Non-Healthcare Sites

For non-healthcare sites, evaluate the privacy risks of TikTok Pixel. TikTok uses advanced matching techniques to reidentify users, including scraping email addresses and matching with social media logins, which poses significant privacy risks.

Risk assessment:

• Understand TikTok's advanced matching and reidentification capabilities
• Evaluate whether TikTok Pixel is necessary for business operations
• Assess privacy impact of TikTok's user identification practices
• Review TikTok's data collection and sharing practices
• Consider regulatory requirements (GDPR, CCPA) that may restrict TikTok Pixel
• Evaluate alternative advertising and analytics solutions
• Document risk assessment findings

Step 3: Gate TikTok Pixel Behind Consent Management - Block Script Entirely

If TikTok Pixel must be retained for non-healthcare use cases, ensure it does NOT load at all when users opt out. Configure your consent management platform and tag manager to completely block TikTok Pixel script execution when users opt out.

Consent gating (block script entirely):

• Categorize TikTok Pixel as 'marketing' or 'advertising' in CMP
• If using tag manager (recommended), configure it to block TikTok Pixel script from loading when users opt out
• Configure CMP to require explicit consent before TikTok Pixel loads
• Ensure opt-out immediately prevents TikTok Pixel script from executing (not just disabling tracking)
• Test using browser Network tab to verify TikTok Pixel script does NOT load when opted out
• Verify complete absence of TikTok Pixel requests
• Test consent flow regularly to verify TikTok Pixel is blocked
• Document consent requirements in privacy policy

Step 4: Disclose TikTok Pixel in Privacy Policy

If TikTok Pixel is retained, clearly disclose its presence and risks in your privacy policy. Users should understand TikTok's data collection practices and reidentification capabilities.

Privacy policy disclosure requirements:

• Explicitly state that TikTok Pixel is present on your website
• Explain TikTok's data collection and reidentification practices
• Describe how TikTok uses advanced matching to identify users
• Explain that TikTok may match users across websites and social media platforms
• Describe what data TikTok Pixel collects
• Provide instructions for opting out
• Include links to TikTok's privacy policy and ad preferences
• Update policy if TikTok Pixel practices change

Step 5: Consider Alternatives to TikTok Pixel

Evaluate alternative advertising and analytics solutions that don't rely on aggressive user reidentification. Consider privacy-preserving alternatives or server-side tracking options.

Alternative evaluation:

• Research privacy-preserving advertising and analytics alternatives
• Consider server-side tracking solutions
• Evaluate aggregated analytics instead of individual tracking
• Assess whether TikTok advertising is essential to business operations
• Test alternative solutions before removing TikTok Pixel
• Plan migration if alternatives are preferable
• Document decision to retain or replace TikTok Pixel

Step 6: Verify TikTok Pixel Is Not Operating in Opt-Out State

Regularly test that TikTok Pixel is completely blocked when users opt out. Use browser developer tools to verify that no TikTok Pixel requests are made and that the script does not load at all.

Testing process:

• Opt out of all non-essential cookies/tracking in consent banner
• Use browser developer tools Network tab to verify NO TikTok Pixel requests are made
• Check that TikTok Pixel script does NOT load at all (not just disabled)
• Verify complete absence of tiktok.com and byteoversea.com requests
• Test across different browsers and devices
• Test with GPC signal enabled to verify TikTok Pixel is blocked
• Document test results and schedule regular testing (monthly recommended)

Tracker Location Data Broker

Reason Code: tracker_location_data_broker

Description: Location data broker tracking technologies are present on the website, which collect and sell precise geolocation data to third parties

Remediation Steps:

Step 1: Understand Location Data Broker Risks

Location data brokers collect precise geolocation information (GPS coordinates, IP-based location, Wi-Fi triangulation) and sell it to third parties. This creates significant privacy risks as location data can reveal sensitive information about users' movements, habits, and personal lives.

Location Data Broker Risks:

• Precise location data can reveal sensitive information (home address, workplace, medical facilities visited, etc.)
• Location data can be used to track users' movements and habits over time
• Location data brokers sell data to third parties without user knowledge
• Location data can be used for stalking, harassment, or other harmful purposes
• Location data collection may violate privacy regulations (GDPR, CCPA)
• Users often don't realize location data is being collected and sold

Common Location Data Brokers:

• Companies specializing in location intelligence and geolocation data
• Advertising technology companies that collect location data
• Data brokers that include location data in their profiles
• Mobile advertising networks that collect GPS and location data

Step 2: Remove Location Data Broker Trackers

The most effective remediation is to completely remove location data broker trackers from your website. Location data brokers collect and sell sensitive geolocation information, which conflicts with user privacy expectations and may violate privacy regulations.

Removal process:

• Identify all location data broker domains (check network requests for location-related endpoints)
• Search your codebase for references to location data broker domains
• Remove location data broker scripts and pixels from page templates
• If using a tag manager, remove location data broker configurations
• Remove location data broker references from vendor lists and documentation
• Verify removal using browser developer tools network tab
• Test across different pages to ensure complete removal
• Monitor for any re-introduction of location data broker trackers
• Update vendor lists to prevent future location data broker additions

Step 3: Gate Location Data Brokers Behind Consent - Block Scripts Entirely

If location data broker trackers cannot be immediately removed, ensure they do NOT load at all when users opt out. Use a tag manager as the enforcement layer to completely block script execution. Configure your consent management platform to require explicit consent.

Consent configuration (block scripts entirely):

• Categorize location data broker trackers as 'marketing' or 'advertising' in CMP
• If using tag manager (recommended), configure it to block location data broker scripts from loading when users opt out
• Configure CMP to require explicit opt-in consent (not pre-checked)
• Ensure opt-out immediately prevents location data broker scripts from executing (complete blocking)
• Test using browser Network tab to verify location data broker scripts do NOT load when opted out
• Verify complete absence of location data broker requests
• Test consent flow regularly to verify blocking
• Document consent requirements in privacy policy

Step 4: Verify GPC Blocks Location Data Brokers

Ensure that Global Privacy Control (GPC) signal also blocks location data broker trackers. GPC should prevent location data collection when enabled, providing an additional layer of protection.

GPC verification:

• Enable GPC signal in your browser or using browser extensions
• Verify that location data broker trackers do NOT load when GPC is enabled
• Test using browser developer tools Network tab
• Ensure CMP and tag manager respect GPC signal for location data brokers
• Document GPC blocking behavior
• Regularly test GPC effectiveness for location data brokers

Step 5: Disclose Location Data Broker Usage in Privacy Policy

If location data brokers are present, your privacy policy must clearly disclose their presence, what location data is collected, how it's used, and provide users with opt-out mechanisms.

Privacy policy disclosure requirements:

• Explicitly state that location data broker trackers are present
• List location data broker partners by name
• Explain what location data is collected (GPS, IP-based, Wi-Fi triangulation)
• Describe how location data is used and sold to third parties
• Explain privacy risks of location data collection
• Provide instructions for opting out
• Include links to location data broker opt-out pages if available
• Explain user rights regarding location data
• Update policy whenever location data broker relationships change

Step 6: Review Vendor Contracts for Location Data Sharing

Review all vendor contracts to identify any location data sharing arrangements. Terminate or modify agreements that allow location data broker access to user geolocation information.

Contract review:

• Audit all third-party vendor agreements
• Identify any clauses that allow location data collection or sharing
• Review data processing addendums (DPAs) for location data provisions
• Terminate or modify agreements to prohibit location data broker sharing
• Update vendor onboarding process to prevent future location data broker agreements
• Document contract review findings and remediation actions

GPC Not Effective on Initial Load

Reason Code: gpc_not_effective_on_initial_load

Description: Global Privacy Control (GPC) signal is not being respected on the initial page load, requiring a page reload before GPC becomes effective, which means tracking technologies load before GPC can be enforced

Remediation Steps:

Step 1: Ensure CMP Loads Before All Tracking Scripts

The most common cause of GPC not being effective on initial load is that tracking scripts load before the consent management platform can read the GPC signal. Ensure your CMP script loads synchronously in the <head> section before any other scripts.

Script Loading Order (Critical):

1. Load CMP script synchronously in the <head> section (before any other scripts)
2. Ensure CMP initialization completes before any tracking scripts execute
3. Configure CMP to read GPC signal immediately upon initialization
4. Block all tracking scripts until CMP has checked GPC signal
5. Use script loading order controls (defer, async, or blocking) appropriately
6. If using a tag manager, configure it to wait for CMP consent signals before firing tags
7. Test script loading order using browser developer tools network tab
8. Verify CMP appears and GPC is read before any tracking requests are made

Step 2: Configure CMP to Read GPC Signal Immediately on Page Load

Configure your consent management platform to read the GPC signal immediately when the page loads, before any tracking scripts are initialized. The CMP should check for GPC as soon as it initializes.

CMP configuration:

• Access your CMP administration panel
• Navigate to GPC or privacy signal settings
• Configure CMP to read GPC signal immediately upon initialization
• Set GPC check to occur before any script execution
• Ensure CMP treats GPC as an immediate opt-out (no banner delay)
• Configure CMP to block all non-essential scripts when GPC is detected
• Test CMP initialization timing using browser developer tools
• Verify GPC is read before any tracking scripts load

Step 3: Configure Tag Manager to Wait for GPC Check Before Loading Tags

If using a tag manager, configure it to wait for the CMP to complete its GPC check before loading any tags. Use tag manager consent mode or custom variables to check GPC signal before tag execution.

Tag Manager Configuration:

• Configure tag manager to wait for CMP consent signals before firing tags
• Enable GPC signal detection in tag manager settings or consent mode
• Create consent state variables that check for GPC signal (navigator.globalPrivacyControl === true)
• Set up triggers that PREVENT tag execution until GPC check is complete
• Configure all tags to check GPC signal before loading
• Use tag manager's built-in consent mode features if available (e.g., Google Tag Manager Consent Mode)
• Test tag manager configuration to ensure tags wait for GPC check
• Verify using browser Network tab that no tags load before GPC is checked

Step 4: Implement Client-Side GPC Check Before Script Execution

For direct script implementations, add client-side code that checks for GPC signal before initializing any tracking technologies. This provides an additional layer of enforcement beyond CMP configuration.

Example Implementation:

// Check for GPC signal immediately on page load
const gpcEnabled = navigator.globalPrivacyControl === true ||
  document.querySelector('meta[name="GPC"]')?.content === '1';

// Block all tracking scripts if GPC is enabled
if (gpcEnabled) {
  // Do not initialize any tracking scripts
  // CMP should handle this, but this provides additional protection
  return;
}

// Only initialize tracking if GPC is not enabled AND consent is granted
if (!gpcEnabled && userConsentGranted) {
  // Initialize tracking scripts
}

• Add GPC check at the very beginning of script execution
• Block script execution entirely if GPC is detected
• Test script behavior with GPC enabled to verify blocking

Step 5: Test GPC Effectiveness on Initial Page Load

Regularly test that GPC signal is respected on the initial page load without requiring a reload. Use browser extensions or developer tools to verify that no tracking scripts load when GPC is enabled on first visit.

Testing methods:

• Use browser extensions like Privacy Badger, DuckDuckGo Privacy Essentials, or similar that send GPC signals
• Manually set GPC signal using browser developer tools before page load
• Test in incognito/private browsing mode (simulate new users)
• Clear cookies and local storage before testing
• Use browser developer tools Network tab to verify NO tracking requests are made on initial load
• Verify that tracking scripts do NOT load at all when GPC is enabled
• Test specific services (e.g., verify Google Analytics script does NOT load)
• Test across different browsers (Chrome, Firefox, Safari, Edge)
• Test from search engine results (simulate user landing from search)
• Verify GPC respect on initial load, not just after reload
• Document test results and schedule regular testing (monthly recommended)

Step 6: Display GPC Acknowledgment Banner on Initial Load

When GPC is detected, display a banner or notification immediately on initial page load that acknowledges GPC is being honored. This provides user feedback and demonstrates GPC compliance.

Banner implementation:

• Configure CMP to display GPC acknowledgment banner when GPC is detected
• Show banner immediately on initial page load (before any tracking)
• Keep banner simple and non-intrusive
• Inform users that their GPC preference is being honored
• Provide option to dismiss banner
• Ensure banner doesn't delay page functionality
• Test banner display on initial load with GPC enabled

Step 7: Work with CMP Provider to Ensure Initial Load Support

If GPC is still not effective on initial load after configuration changes, contact your consent management platform provider. Some CMPs may require specific configuration or updates to support GPC on initial load.

Provider engagement:

• Contact CMP support to report GPC initial load issue
• Request configuration guidance for initial load GPC support
• Ask about CMP updates or features that improve initial load GPC detection
• Verify CMP version supports initial load GPC detection
• Test CMP updates or configuration changes
• Document CMP provider guidance and resolution steps

High Risks

⚠️ Address Promptly

These high risks require prompt remediation.

Pages Missing Consent Banner

Reason Code: consent-banner-missing

Description: Pages that do not display a consent banner or privacy notice to users

Remediation Steps:

Step 1: Implement a Consent Management Platform (CMP)

Deploy a consent management platform (CMP) such as OneTrust, Cookiebot, TrustArc, or similar solution that displays a consent banner on all pages of your website. The CMP should be configured to appear before any tracking technologies are loaded.

Implementation Steps:

1. Select a CMP provider that meets your compliance requirements (GDPR, CCPA, etc.)
2. Install the CMP script in the <head> section of your website template
3. Configure the CMP to display on all pages, including dynamically loaded content
4. Test across different browsers and devices to ensure consistent display

Step 2: Ensure Consent Banner Loads Before Tracking Technologies

The consent banner must load and initialize before any tracking technologies are executed. This ensures users can make consent choices before any data collection occurs.

Implementation checklist:

• Load CMP script synchronously in the <head> section before other scripts
• Ensure CMP initialization completes before any tracking scripts execute
• Use script loading order controls (defer, async, or blocking) appropriately
• If using a tag manager, configure it to wait for CMP consent signals before firing tags
• Test script loading order using browser developer tools network tab
• Verify banner appears before any third-party requests are made

Step 3: Use Tag Manager as Consent Enforcement Layer (Best Practice)

The best practice for consent enforcement is to deploy all tracking technologies through a tag manager (such as Google Tag Manager, Tealium, Adobe Launch, or similar) and configure it as the enforcement layer. The tag manager receives consent signals from your CMP (OneTrust, Cookiebot, TrustArc, etc.) and blocks tags from loading when users opt out. This prevents scripts from executing at all, which is safer than relying on privacy-focused settings.

Why Tag Managers Are Critical for Consent Enforcement:

The Problem with Privacy Settings Alone:

• Many third-party tools (like Google Analytics) have privacy-focused settings, but if the script loads, plaintiffs and regulators see it running
• Even with privacy flags set, the script execution itself can be seen as non-compliant
• The safest approach is to completely block scripts from loading when users opt out

Tag Manager Configuration (Best Practice):

• Deploy ALL tracking technologies through your tag manager (not directly in page templates)
• Configure tag manager to receive consent signals from your CMP
• Set up trigger conditions that PREVENT tags from firing when users opt out
• Use consent state variables to control tag execution
• Enable consent mode features if available (e.g., Google Tag Manager Consent Mode)
• Configure tag manager to completely block script loading (not just disable tracking)
• Regularly audit tag manager configuration to ensure all third-party tags are properly gated

If Using Direct Script Implementations (Not Recommended):

• Add consent checks BEFORE initializing any tracking scripts
• Completely prevent script loading when users opt out (don't just disable tracking)
• Use conditional loading based on consent state
• Implement script blockers that prevent script execution entirely
• Test that scripts do not load at all when users opt out

Important: When users opt out, third-party scripts should NOT load or execute. Do not rely on privacy settings within scripts - block the scripts entirely.

Step 4: Ensure Banner Appears on All Page Types

Verify that your consent banner appears on all page types including landing pages, dynamically loaded content, single-page application (SPA) routes, and pages loaded via AJAX or iframe embeds.

Coverage checklist:

• Include consent banner initialization in main page templates
• Add banner initialization to SPA route handlers and navigation events
• Ensure banner appears in dynamically loaded content sections
• Test banner display in embedded iframe contexts (if applicable)
• Verify banner appears on error pages and redirects
• Test across different content management systems or frameworks if applicable

Step 5: Regularly Test Consent Manager Effectiveness (Critical)

Consent management is NOT set-and-forget. You must regularly test that your consent manager actually prevents tracking technologies from loading when users opt out. Many organizations assume their consent manager works correctly, but new tags are added frequently (often directly in page templates), and these may bypass consent controls. Regular testing is essential.

Why Regular Testing Is Critical:

• New tags are added frequently, often directly in page templates without going through tag manager
• Tag manager configurations can become outdated
• Consent manager rules may not cover all third-party domains
• Scripts may load before consent checks complete
• Many organizations never test their consent manager after initial setup

Testing Checklist (Perform Monthly or When Adding New Tags):

1. Test Opt-Out Functionality:

   • Opt out of all non-essential cookies/tracking
   • Use browser developer tools Network tab to verify NO third-party tracking requests are made
   • Check that tracking scripts do NOT load at all (not just disabled)
   • Verify scripts are completely blocked, not just using privacy settings

2. Test Specific Third-Party Services:

   • Verify Google Analytics does NOT load when opted out (check for gtag.js or analytics.js requests)
   • Verify Meta Pixel does NOT load when opted out
   • Verify other marketing/advertising tags are blocked
   • Test each category of tracking (analytics, marketing, advertising)

3. Test Across Scenarios:

   • Test in incognito/private browsing mode (simulate new users)
   • Test after clearing cookies and local storage
   • Test with browser extensions that send GPC signals
   • Test across different browsers (Chrome, Firefox, Safari, Edge)
   • Test on mobile devices

4. Verify Script Blocking (Not Just Privacy Settings):

   • Confirm scripts do NOT execute at all when opted out
   • Do not rely on privacy-focused settings within scripts
   • Check Network tab for complete absence of tracking requests
   • Verify tag manager is actually blocking script loading

5. Document Test Results:

   • Keep records of testing dates and results
   • Document any issues found and remediation steps
   • Update consent manager configuration based on test results

Step 6: Establish Ongoing Consent Management Maintenance Process

Consent management requires ongoing maintenance. New tags are constantly added, and they must be properly configured to respect consent. Establish a process to ensure all new tags go through proper consent gating.

Maintenance process:

• Require all new tags to be deployed through tag manager (not directly in templates)
• Review and approve all new third-party scripts before deployment
• Ensure new tags are properly categorized in consent manager
• Configure new tags to respect consent signals before going live
• Test new tags with opt-out to verify they are blocked
• Regularly audit all tags to ensure they're properly gated
• Update consent manager rules when new third-party domains are added
• Document all tags and their consent requirements
• Schedule quarterly reviews of consent manager effectiveness

Trackers Present with GPC

Reason Code: trackers-present-with-gpc

Description: Tracking technologies are loading even when Global Privacy Control signal is enabled, indicating GPC is not being properly enforced

Remediation Steps:

Step 1: Review and Update Consent Manager Rules

The most common cause of trackers loading with GPC enabled is incorrect rule configuration in your consent management platform. Review each tracker domain and ensure it's properly categorized and blocked when GPC is detected.

Action Items:

• Audit all third-party domains in your CMP
• Categorize each domain correctly (marketing, analytics, functional, etc.)
• Ensure non-essential trackers require consent
• Verify GPC signal triggers blocking for all non-essential categories
• Test each tracker individually to confirm blocking behavior

Step 2: Configure Tag Manager to Block Scripts When GPC Detected (Best Practice)

The safest approach is to use a tag manager (such as Google Tag Manager, Tealium, Adobe Launch, or similar) as the enforcement layer. Configure the tag manager to completely block scripts from loading when GPC is detected. Do not rely on privacy-focused settings within scripts - block the scripts entirely. For direct script implementations, add GPC detection that prevents script execution.

Critical: Block Scripts, Don't Rely on Privacy Settings

Even if third-party tools have privacy-focused settings, if the script loads, it can be seen as non-compliant. For example, Google Analytics may have privacy settings, but if the script runs when GPC is enabled, plaintiffs and regulators see it executing. The safest approach is to completely prevent scripts from loading.

Tag Manager Configuration (Recommended):

• Deploy all tracking technologies through tag manager (not directly in templates)
• Enable GPC signal detection in tag manager settings or consent mode
• Create consent state variables that check for both user consent AND GPC signal
• Configure all tags to COMPLETELY BLOCK loading when GPC is detected
• Use tag manager's built-in consent mode features if available (e.g., Google Tag Manager Consent Mode)
• Set up triggers that PREVENT script execution entirely when GPC is detected
• Do not rely on privacy settings within scripts - block scripts from loading
• Test that scripts do NOT load at all when GPC is enabled (use browser Network tab)

If Using Direct Script Implementations (Not Recommended):

• Add GPC detection checks BEFORE initializing any tracking scripts
• Check for navigator.globalPrivacyControl === true or document.querySelector('meta[name="GPC"]')
• Completely prevent script loading if GPC is detected (don't just disable tracking)
• Block script execution entirely, not just use privacy settings
• Test script behavior with GPC enabled to verify complete blocking

Step 3: Implement Client-Side GPC Detection Script

For direct script implementations, add client-side code that checks for GPC signal before initializing tracking technologies. This provides an additional layer of enforcement beyond CMP configuration.

Example Implementation:

// Check for GPC signal
const gpcEnabled = navigator.globalPrivacyControl === true ||
  document.querySelector('meta[name="GPC"]')?.content === '1';

// Only initialize tracking if GPC is not enabled
if (!gpcEnabled && userConsentGranted) {
  // Initialize tracking scripts
}

Step 4: Audit Third-Party Script Loading Order

Some third-party scripts may load before consent or GPC checks can be performed. This is a common cause of trackers loading despite GPC being enabled. Review your script loading order and ensure consent/GPC checks happen before any tracking scripts are executed.

Script loading best practices:

• Load CMP script synchronously in the <head> section before other scripts
• Ensure CMP initialization completes before any tracking scripts execute
• Defer or async load tracking scripts only after consent/GPC check is complete
• Use script blockers or conditional loading based on consent state and GPC signal
• Consider using Content Security Policy (CSP) to control script execution
• Review and minimize third-party script dependencies
• Test script loading order using browser developer tools network tab
• Verify that no tracking requests occur before consent banner appears

Step 5: Regularly Test GPC Signal Detection and Script Blocking

Regularly test that GPC signal is being properly detected and that tracking scripts are completely blocked (not just using privacy settings) when GPC is enabled. Use browser developer tools to verify scripts do NOT load at all.

Testing methods:

• Use browser extensions like Privacy Badger, DuckDuckGo Privacy Essentials, or similar that send GPC signals
• Manually set Sec-GPC: 1 header using browser developer tools
• Check browser console for GPC detection (navigator.globalPrivacyControl)
• Use Network tab in browser developer tools to verify NO tracking requests are made when GPC is enabled
• Verify that tracking scripts do NOT load at all (check for complete absence of script requests)
• Do not rely on privacy settings - verify scripts are completely blocked
• Test specific services (e.g., verify Google Analytics script does NOT load, not just that it has privacy settings)
• Test across different browsers (Chrome, Firefox, Safari, Edge)
• Verify GPC respect persists across page navigation
• Compare behavior with explicit opt-out to ensure they match
• Document test results and schedule regular testing (monthly recommended)

Session Replay Domains

Reason Code: session-replay-domains

Description: Session replay tools are present that record user interactions, mouse movements, and screen activity, which can capture sensitive information

Remediation Steps:

Step 1: Configure Form Field Masking

Configure your session replay tool to mask or exclude form fields that contain sensitive information. Most session replay tools provide data attributes or configuration options to prevent recording of specific form fields. This is the first line of defense against capturing sensitive data.

Masking Implementation:

Step 1: Identify sensitive form fields

• Password fields
• Email address fields
• Credit card and payment information fields
• Social Security Numbers (SSN)
• Phone numbers
• Address fields
• Any custom fields containing PII

Step 2: Add masking attributes Most session replay tools use data attributes. Common patterns:

<!-- Hotjar example -->
<input type="email" data-hj-whitelist />

<!-- FullStory example -->
<input type="password" data-fs-mask />

<!-- Generic pattern (check your tool's documentation) -->
<input type="email" data-session-replay-mask="true" />
<input type="password" data-session-replay-mask="true" />

Step 3: Configure tool settings

• Access your session replay tool's administration panel
• Enable automatic PII detection if available
• Configure tool to recognize your masking attributes
• Set up custom masking rules for domain-specific sensitive fields
• Test masking to ensure sensitive data is not recorded in session replays
• Document masking configuration for future reference and audits

Step 2: Exclude Sensitive Pages from Session Replay

Configure session replay tools to exclude entire pages or page sections that contain sensitive information, such as checkout pages, account pages, or pages with healthcare information.

Page exclusion configuration:

• Identify all pages with sensitive information
• Configure session replay tool to exclude these pages
• Use URL patterns or page identifiers for exclusion
• Test exclusions to verify session replay is disabled
• Regularly review and update exclusion lists

Step 3: Gate Session Replay Behind Explicit Consent - Block Script Entirely

Ensure session replay tool scripts do NOT load at all when users opt out. Use a tag manager as the enforcement layer to completely block script execution. Configure your consent management platform to require explicit consent for session replay, categorized as 'analytics' or 'functional'.

Consent configuration (block script entirely):

• Categorize session replay as requiring consent in CMP
• If using tag manager (recommended), configure it to block session replay scripts from loading when users opt out
• Require explicit opt-in (not pre-checked)
• Ensure opt-out immediately prevents session replay scripts from executing (complete blocking, not just disabling recording)
• Test using browser Network tab to verify session replay scripts do NOT load when opted out
• Verify complete absence of session replay requests
• Clearly disclose session replay usage in privacy policy
• Provide users with information about what session replay records
• Test consent flow regularly to verify blocking

Step 4: Use Privacy-Focused Session Replay Configuration

Configure session replay tools with the most privacy-focused settings available. Disable features like keystroke recording, text capture, and full page recording in favor of aggregated analytics.

Privacy-focused settings:

• Disable keystroke recording
• Disable text content capture
• Use aggregated heatmaps instead of individual session recordings
• Enable IP address anonymization
• Configure data retention to minimum necessary period
• Use server-side filtering to exclude sensitive data

Step 5: Implement Server-Side Data Filtering

If your session replay tool supports it, implement server-side filtering to automatically detect and redact sensitive information before storing session recordings.

Server-side filtering:

• Enable automatic PII detection and redaction
• Configure pattern matching for credit cards, SSNs, emails
• Set up custom filters for domain-specific sensitive data
• Review filtered recordings to verify effectiveness
• Update filters as new sensitive data patterns are identified

Step 6: Update Privacy Policy to Disclose Session Replay

Clearly disclose session replay usage in your privacy policy, explaining what is recorded, how it's used, data retention, and user rights.

Privacy policy disclosure:

• Explain what session replay is and what it records
• Describe how session replay data is used
• Specify data retention periods
• Explain user rights regarding session replay data
• Provide instructions for opting out
• Include links to session replay vendor privacy policies

Chatbot with Session Replay

Reason Code: chatbot-with-session-replay

Description: Chatbot tools are present that include session replay capabilities, which can record user interactions and sensitive information shared during chat sessions

Remediation Steps:

Step 1: Disable Session Replay in Chatbot Configuration

Configure your chatbot tool to disable session replay features. Most chatbot platforms provide settings to turn off recording and replay functionality while retaining chat functionality.

Configuration steps:

• Access chatbot administration panel
• Navigate to session replay or recording settings
• Disable session replay/recording features
• Verify that chat functionality still works without replay
• Test chatbot to ensure no recording is occurring

Step 2: Configure Chatbot to Mask Sensitive Information

If session replay must be retained, configure the chatbot to automatically detect and mask sensitive information (PII, payment details, health information) before recording.

Masking configuration:

• Enable automatic PII detection in chatbot settings
• Configure pattern matching for sensitive data types
• Set up custom masking rules for domain-specific data
• Test masking to ensure sensitive information is properly redacted
• Regularly review and update masking rules

Step 3: Gate Chatbot Behind Consent Management - Block Script Entirely

Ensure chatbot scripts (and session replay features) do NOT load at all when users opt out. Use a tag manager as the enforcement layer to completely block script execution. Configure your consent management platform to require explicit consent for chatbot functionality.

Consent configuration (block script entirely):

• Categorize chatbot as requiring consent in CMP
• If using tag manager (recommended), configure it to block chatbot scripts from loading when users opt out
• Require explicit opt-in for chatbot and session replay
• Ensure opt-out immediately prevents chatbot scripts from executing (complete blocking)
• Test using browser Network tab to verify chatbot scripts do NOT load when opted out
• Verify complete absence of chatbot requests
• Clearly disclose chatbot recording in privacy policy
• Provide users with information about what is recorded
• Test consent flow regularly to verify blocking

Step 4: Use Chatbot Without Session Replay Features

Consider switching to a chatbot provider that doesn't include session replay capabilities, or use a chatbot configuration that excludes replay features entirely.

Alternative approaches:

• Research chatbot providers without session replay
• Evaluate chatbot functionality requirements
• Test alternative chatbot solutions
• Plan migration if switching providers
• Update chatbot implementation documentation

Step 5: Implement Chat Transcript Privacy Controls

If chat transcripts are stored, implement privacy controls including data minimization, encryption, access controls, and retention policies.

Privacy controls:

• Encrypt chat transcripts at rest
• Implement access controls and audit logging
• Set data retention policies and automatic deletion
• Provide users with access to their chat transcripts
• Enable user deletion requests for chat data

Page URL Shared with Third Party

Reason Code: page-url-shared-with-third-party

Description: Page URLs are being shared with third-party domains, which can expose sensitive information embedded in URLs such as search terms, user identifiers, or personal data

Remediation Steps:

Step 1: Sanitize URLs Before Sharing with Third Parties

Implement URL sanitization to remove sensitive information (query parameters, user IDs, search terms) before URLs are sent to third-party domains. Send only generic page identifiers instead of full URLs.

URL Sanitization Strategies:

• Remove query parameters containing sensitive data
• Replace descriptive URLs with generic identifiers
• Strip user IDs and session tokens from URLs
• Remove search terms and filters from URLs
• Use page type identifiers instead of full paths

Example:

// Sanitize URL before sending to third party
const sanitizedUrl = window.location.pathname; // Remove query string
// Or use generic identifier
const pageIdentifier = 'product-page'; // Instead of full URL

Step 2: Use Generic Page Identifiers Instead of URLs

Replace URL sharing with generic page type identifiers (e.g., 'product-page', 'checkout-page') that don't contain sensitive information. This maintains analytics value without exposing URL details.

Implementation approach:

• Map page types to generic identifiers
• Send page type identifiers instead of URLs
• Update analytics and tracking configurations
• Test to ensure analytics still function with identifiers
• Document identifier mapping for reference

Step 3: Implement Referrer Policy

Use HTTP Referrer-Policy headers to control what URL information is sent to third parties. Set appropriate referrer policy levels to limit URL exposure.

Referrer Policy Options:

• no-referrer: Don't send referrer at all
• same-origin: Only send referrer for same-origin requests
• strict-origin-when-cross-origin: Send full URL for same-origin, origin only for cross-origin
• origin: Send only origin, not full URL

Implementation:

<meta name="referrer" content="strict-origin-when-cross-origin">

Or via HTTP header:

Referrer-Policy: strict-origin-when-cross-origin

Step 4: Gate URL-Sharing Trackers Behind Consent - Block Scripts Entirely

Ensure trackers that share URLs do NOT load at all when users opt out. Use a tag manager as the enforcement layer to completely block script execution. Configure your consent management platform to signal the tag manager to prevent these trackers from loading until consent is granted.

Consent configuration (block scripts entirely):

• Identify trackers that share URLs
• Categorize as requiring consent in CMP
• If using tag manager (recommended), configure it to block these tracker scripts from loading when users opt out
• Configure CMP to signal tag manager to prevent loading until consent granted
• Ensure opt-out immediately prevents tracker scripts from executing (complete blocking)
• Test using browser Network tab to verify tracker scripts do NOT load when opted out
• Verify complete absence of URL-sharing tracker requests
• Test consent flow regularly to verify blocking

Step 5: Remove Sensitive Information from URLs

Redesign URL structure to avoid embedding sensitive information. Use POST requests for sensitive data instead of GET requests with query parameters, and avoid user IDs or personal data in URLs.

URL design best practices:

• Use POST for form submissions with sensitive data
• Avoid user IDs and personal data in URLs
• Use session-based authentication instead of URL tokens
• Remove search terms from URLs when possible
• Use clean, generic URL structures

Third Party iFrame Tracker Domains

Reason Code: third-party-iframe-tracker-domains

Description: Third-party tracking technologies are being loaded via iframes, which can bypass some privacy controls and consent mechanisms

Remediation Steps:

Step 1: Remove Unnecessary iFrame Trackers

Review all iframe-embedded trackers and remove those that are not essential. iFrame trackers can be more difficult to control and may bypass some consent mechanisms.

Removal process:

• Identify all iframe-embedded trackers
• Evaluate necessity of each iframe tracker
• Remove non-essential iframe trackers
• Replace with direct script implementations where possible
• Verify removal using browser developer tools

Step 2: Implement Consent Gating for iFrame Trackers - Block Entirely When Opted Out

Ensure iframe trackers do NOT load at all when users opt out. Use a tag manager as the enforcement layer to completely block iframe creation. For direct implementations, conditionally load iframes only when consent is granted. Do not rely on privacy settings - block iframes entirely.

Conditional Loading Implementation (Block Entirely):

If using a tag manager (Recommended):

• Configure tag manager to check consent state before creating iframe
• Use tag manager consent variables or consent mode features
• Set up triggers that PREVENT iframe creation until consent is granted
• Completely block iframe loading when users opt out (not just disable tracking)
• Test using browser Network tab to verify iframes do NOT load when opted out
• Verify complete absence of iframe requests
• Monitor iframe loading behavior using browser developer tools

For direct script implementations:

// Check consent state and GPC before loading iframe tracker
// IMPORTANT: Only create iframe if consent granted AND GPC not enabled
const userConsentGranted = /* check your CMP consent state */;
const gpcEnabled = navigator.globalPrivacyControl === true;

// Completely prevent iframe creation if user opted out
if (userConsentGranted && !gpcEnabled) {
  const iframe = document.createElement('iframe');
  iframe.src = 'https://tracker.example.com';
  document.body.appendChild(iframe);
}
// If user opted out, iframe is never created

• Test consent flow to verify complete blocking
• Verify iframes do NOT load at all when opted out

Step 3: Use Sandbox Attributes for iFrame Security

Apply sandbox attributes to iframes to restrict their capabilities and prevent them from executing scripts or accessing parent page data without explicit permission.

Sandbox Implementation:

<iframe src="https://tracker.example.com"
  sandbox="allow-scripts allow-same-origin"
  loading="lazy">&lt;/iframe&gt;

• Use sandbox attribute to restrict iframe capabilities
• Only allow necessary permissions
• Prevents iframe from accessing parent page
• Reduces security and privacy risks

Step 4: Implement Content Security Policy (CSP)

Use Content Security Policy headers to control which domains can be embedded as iframes. This provides an additional layer of control over iframe loading.

CSP Configuration:

Content-Security-Policy: frame-src 'self' https://trusted-domain.com;

• Specify allowed iframe sources
• Block untrusted domains
• Use 'self' to restrict to same origin
• Regularly review and update CSP rules

Step 5: Replace iFrame Trackers with Direct Implementations

Where possible, replace iframe-embedded trackers with direct script implementations that are easier to control and gate behind consent management.

Replacement process:

• Identify iframe trackers that can be replaced
• Research direct implementation options
• Test direct implementations for functionality
• Replace iframe with direct script
• Verify tracking still works correctly
• Remove old iframe implementations

Fingerprint Weighting 41 Plus

Reason Code: fingerprint_weighting_41_plus

Description: Third-party scripts detected performing excessive browser fingerprinting by calling numerous DOM methods used to identify and track users across websites

Remediation Steps:

Step 1: Evaluate Third-Party Fingerprinter Legitimacy and Purpose

First, identify which third-party service is performing fingerprinting and evaluate whether it's legitimate and necessary. Some fingerprinting is used for fraud prevention, but much of it is for tracking purposes.

Evaluation process:

• Identify the third-party domain performing fingerprinting from network requests
• Determine the purpose of the fingerprinting (fraud prevention, analytics, advertising, etc.)
• Verify if the service is disclosed in your privacy policy
• Assess whether fingerprinting is necessary for your business operations
• Review vendor documentation to understand fingerprinting purpose
• Check if fingerprinting is optional and can be stopped with consent management
• Document evaluation findings and business justification

Step 2: Gate Fingerprinters Behind Consent Management - Block Script Entirely

Ensure fingerprinting scripts do NOT load at all when users opt out. Fingerprinting should be optional and require explicit consent. Use a tag manager as the enforcement layer to completely block script execution.

Consent configuration (block script entirely):

• Categorize fingerprinting services as 'marketing' or 'analytics' in CMP (not essential)
• If using tag manager (recommended), configure it to block fingerprinting scripts from loading when users opt out
• Configure CMP to require explicit consent for fingerprinting
• Ensure opt-out immediately prevents fingerprinting scripts from executing (complete blocking, not just disabling)
• Test using browser Network tab to verify fingerprinting scripts do NOT load when opted out
• Verify complete absence of fingerprinting requests
• Test consent flow regularly to verify blocking
• Document consent requirements in privacy policy

Step 3: Disclose Fingerprinting in Privacy Policy

If fingerprinting is retained, clearly disclose it in your privacy policy. Users should understand that fingerprinting is occurring, what data is collected, and how it's used.

Privacy policy disclosure requirements:

• Explicitly state that browser fingerprinting is used
• Identify which third-party services perform fingerprinting
• Explain what browser characteristics are collected (screen resolution, fonts, plugins, etc.)
• Describe how fingerprinting data is used (fraud prevention, tracking, etc.)
• Explain that fingerprinting can identify users across websites
• Provide information about user rights regarding fingerprinting
• Include instructions for opting out of fingerprinting
• Update policy whenever fingerprinting practices change

Step 4: Consider Alternatives to Fingerprinting

Evaluate whether fingerprinting is truly necessary. For fraud prevention, consider alternative methods that don't rely on extensive browser fingerprinting. For analytics, consider privacy-preserving alternatives.

Alternative evaluation:

• For fraud prevention: Evaluate risk-based authentication methods that don't require extensive fingerprinting
• For analytics: Consider server-side analytics or privacy-preserving measurement techniques
• For advertising: Use consent-based tracking instead of fingerprinting
• Research vendor alternatives that don't rely on fingerprinting
• Test alternatives to ensure functionality is maintained
• Plan migration if alternatives are preferable
• Document decision to retain or replace fingerprinting

Step 5: Implement Fingerprinting Detection and Monitoring

Regularly monitor your website to detect new fingerprinting scripts. Use browser developer tools and privacy scanning tools to identify when new fingerprinters are added.

Monitoring process:

• Use browser developer tools to monitor DOM method calls
• Implement automated scanning to detect fingerprinting patterns
• Review network requests for fingerprinting-related endpoints
• Monitor for new third-party scripts that may perform fingerprinting
• Set up alerts for fingerprinting detection
• Regularly audit third-party scripts for fingerprinting behavior
• Document all fingerprinting services and their purposes

Bad SSL Domains

Reason Code: bad_ssl_domains

Description: Third-party domains with SSL certificate issues (expired, invalid, self-signed, or misconfigured certificates) that trigger browser security warnings

Remediation Steps:

Step 1: Contact Third-Party Vendor About Certificate Issues

Contact the third-party vendor to report SSL certificate issues. Most certificate problems are temporary and can be resolved by the vendor. Document the issue and request resolution timeline.

Contact process:

• Identify the third-party domain with certificate issues
• Document the specific certificate error (expired, invalid, self-signed, etc.)
• Contact vendor support to report the certificate issue
• Request resolution timeline and certificate update schedule
• Follow up if issue is not resolved promptly
• Document vendor response and resolution status
• Monitor certificate status after vendor reports resolution

Step 2: Assess Third-Party Reliability and Necessity

If a third-party vendor consistently has certificate issues, evaluate whether they are reliable and necessary. Frequent certificate problems may indicate poor security practices or vendor instability.

Assessment process:

• Review history of certificate issues with the vendor
• Evaluate vendor's overall security practices and reliability
• Assess whether the vendor's service is essential to your website
• Consider vendor's response time and resolution of certificate issues
• Review vendor's security certifications and compliance status
• Evaluate alternative vendors if certificate issues persist
• Document assessment findings and decision rationale

Step 3: Remove Third-Party Services with Persistent Certificate Issues

If a third-party vendor has persistent certificate issues and cannot resolve them, remove the service. Unreliable SSL certificates pose security risks and create poor user experience.

Removal process:

• Identify all references to the problematic third-party domain
• Remove script tags, iframe sources, and API endpoints
• Remove from tag manager configurations
• Verify removal using browser developer tools
• Test website functionality after removal
• Monitor for any re-introduction of the problematic domain
• Document removal and business justification

Step 4: Replace with Reliable Alternatives

If the third-party service is essential, replace it with a reliable alternative that maintains proper SSL certificates. Research vendors with strong security practices and certificate management.

Replacement process:

• Identify the functionality provided by the problematic service
• Research reliable alternatives with similar capabilities
• Verify alternative vendors maintain proper SSL certificates
• Evaluate alternative vendors' security practices
• Test replacement solution before full deployment
• Update documentation and vendor lists
• Monitor replacement solution for certificate issues

Step 5: Implement SSL Certificate Monitoring

Establish monitoring for third-party SSL certificates to detect certificate issues early. Use automated tools to check certificate validity and expiration dates.

Monitoring Strategies:

• Use SSL certificate monitoring services to track third-party certificates
• Set up automated checks for certificate expiration dates
• Monitor for certificate validation errors
• Set up alerts for certificate issues
• Regularly review SSL certificate status for all third-party domains
• Document certificate monitoring process and alert procedures
• Review and update monitoring as new third parties are added

Medium Risks

ℹ️ Should Be Addressed

These medium risks require review and remediation.

Chatbot Domains

Reason Code: chatbot-domains

Description: Chatbot tools are present on the website, which may collect user interactions and personal information

Remediation Steps:

Step 1: Gate Chatbot Behind Consent Management - Block Script Entirely

Ensure chatbot scripts do NOT load at all when users opt out. Use a tag manager as the enforcement layer to completely block script execution. Configure your consent management platform to require consent for chatbot functionality, categorized as 'functional' or 'analytics'.

Consent configuration (block script entirely):

• Categorize chatbot as requiring consent in CMP
• If using tag manager (recommended), configure it to block chatbot scripts from loading when users opt out
• Require explicit opt-in before chatbot loads
• Ensure opt-out immediately prevents chatbot scripts from executing (complete blocking)
• Test using browser Network tab to verify chatbot scripts do NOT load when opted out
• Verify complete absence of chatbot requests
• Clearly disclose chatbot usage in privacy policy
• Provide users with information about chatbot data collection
• Test consent flow regularly to verify blocking

Step 2: Configure Chatbot Privacy Settings

Review and configure chatbot privacy settings to minimize data collection. Disable unnecessary data collection features and enable privacy-focused options.

Privacy settings:

• Disable unnecessary analytics and tracking
• Enable IP address anonymization
• Configure data retention to minimum necessary period
• Disable cross-site tracking if available
• Review and limit data sharing with third parties

Step 3: Implement Data Minimization

Configure chatbot to collect only the minimum data necessary for functionality. Avoid collecting unnecessary personal information during chat interactions.

Data minimization:

• Review chatbot data collection fields
• Remove unnecessary data collection
• Use generic identifiers instead of PII when possible
• Implement progressive data collection (only collect what's needed)
• Regularly audit chatbot data collection practices

Step 4: Update Privacy Policy to Disclose Chatbot Usage

Clearly disclose chatbot usage in your privacy policy, including what data is collected, how it's used, stored, and shared.

Privacy policy disclosure:

• Explain chatbot presence and purpose
• Describe what data chatbot collects
• Explain how chat data is used and stored
• Specify data retention periods
• Describe data sharing practices
• Provide user rights information

Social Media Domain

Reason Code: social-media-domain

Description: Social media tracking domains are present on the website

Remediation Steps:

Step 1: Gate Social Media Trackers Behind Consent - Block Scripts Entirely

Ensure all social media tracker scripts do NOT load at all when users opt out. Use a tag manager as the enforcement layer to completely block script execution. Configure your consent management platform to signal the tag manager to prevent social tracker loading until marketing/advertising consent is granted.

Consent configuration (block scripts entirely):

• Categorize social media domains as 'marketing' or 'advertising' in CMP
• If using tag manager (recommended), configure it to block social tracker scripts from loading when users opt out
• Require explicit opt-in consent
• Ensure opt-out immediately prevents social tracker scripts from executing (complete blocking, not just privacy settings)
• Test using browser Network tab to verify social tracker scripts do NOT load when opted out
• Verify complete absence of social tracker requests
• Test consent flow regularly to verify proper blocking
• Document consent requirements in privacy policy

Step 2: Consider Using a Tag Manager for Centralized Control

If you're managing multiple social media trackers, consider deploying them through a tag manager (such as Google Tag Manager, Adobe Launch, or similar) rather than hardcoding scripts. Tag managers provide better consent enforcement and easier centralized management.

Tag manager benefits:

• Centralized social tracker management in one interface

• Better consent enforcement through tag manager consent mode features

• Easier to add/remove social trackers without code changes

• Better control over firing conditions and page-level restrictions

• Simplified testing and debugging with preview modes

• Note: Tag managers are optional. If using direct script implementations, ensure you implement proper consent gating manually.

Step 3: Limit Social Trackers to Specific Pages

Restrict social media trackers to specific pages where they provide value (e.g., marketing pages) and exclude them from sensitive pages (forms, account pages, healthcare content).

Page-level restrictions:

• Identify pages where social trackers are acceptable
• Configure tag manager with page-level conditions
• Exclude social trackers from sensitive pages
• Use URL-based rules to control loading
• Regularly audit page-level configurations

Step 4: Review and Minimize Social Tracker Usage

Conduct a review to determine if all social media trackers are necessary. Remove redundant trackers and consolidate functionality where possible.

Review process:

• List all social media trackers and their purposes
• Identify redundant or unnecessary trackers
• Evaluate business value versus privacy impact
• Remove trackers that don't provide sufficient value
• Document removal decisions and business justification

Cookies

Reason Code: cookies

Description: Excessive cookie usage, particularly third-party cookies, which can impact user privacy

Remediation Steps:

Step 1: Implement Comprehensive Cookie Consent Management

Deploy a consent management platform that provides granular cookie control. Users should be able to accept or reject cookies by category (essential, analytics, marketing, etc.).

Cookie consent implementation:

• Deploy CMP with granular cookie categorization
• Provide clear cookie descriptions and purposes
• Enable category-level consent (not just accept all/reject all)
• Ensure consent choices are respected
• Provide easy mechanism for users to change consent preferences

Step 2: Minimize Third-Party Cookie Usage

Reduce reliance on third-party cookies by using first-party alternatives where possible, implementing server-side tracking, or using privacy-preserving measurement techniques.

Reduction strategies:

• Replace third-party analytics with first-party solutions
• Use server-side tracking instead of client-side cookies
• Implement privacy-preserving measurement (e.g., Google Analytics 4 with consent mode)
• Use aggregated analytics instead of individual tracking
• Evaluate whether all third-party cookies are necessary

Step 3: Implement Cookie Classification and Labeling

Properly classify all cookies (essential, functional, analytics, marketing) and ensure they're correctly labeled in your cookie consent banner. This helps users make informed choices.

Classification process:

• Audit all cookies set on your website
• Classify each cookie by purpose and type
• Update CMP with accurate cookie classifications
• Ensure cookie descriptions are clear and accurate
• Regularly review and update classifications

Step 4: Set Appropriate Cookie Expiration

Review cookie expiration times and set them to the minimum necessary period. Avoid unnecessarily long expiration times that persist user data longer than needed.

Expiration review:

• Audit cookie expiration times
• Set expiration to minimum necessary period
• Use session cookies where persistent storage isn't needed
• Implement automatic cookie cleanup
• Document cookie expiration policies

Step 5: Provide Clear Cookie Information

Maintain a comprehensive cookie policy that lists all cookies, their purposes, expiration, and whether they're first-party or third-party. Make this easily accessible to users.

Cookie policy requirements:

• List all cookies with clear descriptions
• Specify cookie purposes and categories
• Indicate first-party vs third-party status
• Provide expiration information
• Explain how users can manage cookies
• Update policy regularly as cookies change

Third-Party Trackers Inventory

Reason Code: third-party-trackers-inventory

Description: A comprehensive inventory of third-party tracking domains present on the website

Remediation Steps:

Step 1: Conduct Regular Tracker Audits

Establish a process for regularly auditing all third-party trackers on your website. Document each tracker's purpose, business justification, and data collection practices.

Audit process:

• Maintain inventory of all third-party trackers
• Document business purpose for each tracker
• Review data collection and sharing practices
• Assess privacy impact of each tracker
• Identify opportunities for removal or consolidation
• Conduct audits quarterly or when new trackers are added

Step 2: Implement Consent Management - Block Scripts Entirely When Opted Out

Ensure all non-essential trackers are properly gated behind consent management. Use a tag manager as the enforcement layer to completely block scripts from loading when users opt out. Regularly test to verify scripts are actually blocked.

Consent management:

• Categorize all trackers (essential, analytics, marketing, etc.) in CMP
• Deploy all trackers through tag manager (not directly in templates)
• Configure tag manager to receive consent signals from CMP
• Configure tag manager to COMPLETELY BLOCK script loading for non-essential trackers when users opt out
• Ensure opt-out prevents non-essential tracker scripts from executing (complete blocking, not privacy settings)
• Test consent flow regularly using browser Network tab to verify scripts do NOT load when opted out
• Verify complete absence of tracking requests
• Monitor consent rates and adjust as needed
• Schedule regular testing to ensure consent manager continues to work

Step 3: Consider Using a Tag Manager for Centralized Management

If you're managing many trackers, consider deploying them through a tag manager (such as Google Tag Manager, Adobe Launch, Tealium, or similar) for centralized control, easier management, and better consent enforcement.

Tag manager benefits:

• Centralized tracker configuration and management in one interface

• Easier consent enforcement through built-in consent mode features

• Simplified testing and debugging with preview/debug modes

• Better control over firing conditions and triggers

• Easier to add/remove trackers without code deployments

• Built-in integration with many consent management platforms

• Note: Tag managers are optional. If you prefer direct script implementations, ensure you implement proper consent gating and tracker management manually.

Step 4: Establish Tracker Approval Process

Create a formal approval process for adding new trackers. Require business justification, privacy impact assessment, and consent management plan before approval.

Approval process:

• Require business justification for new trackers
• Conduct privacy impact assessment
• Verify consent management requirements
• Review data sharing and retention policies
• Set sunset dates and review cycles
• Document approval decisions

Step 5: Maintain Transparent Tracker Disclosure

Keep your privacy policy and cookie policy updated with accurate information about all trackers, their purposes, and data collection practices.

Disclosure requirements:

• List all trackers in privacy policy
• Explain purpose and data collection for each
• Describe data sharing practices
• Provide user rights information
• Update policies when trackers change
• Make policies easily accessible

Third Party iFrame Domains

Reason Code: third-party-iframe-domains

Description: Third-party content (not classified as trackers) is being loaded via iframes

Remediation Steps:

Step 1: Review iFrame Necessity and Purpose

Conduct a review of all third-party iframes to determine if they're necessary and serve a legitimate business purpose. Remove iframes that are not essential.

Review process:

• List all third-party iframes on your website
• Document purpose and business justification
• Evaluate whether iframe is necessary
• Identify alternatives to iframe implementation
• Remove unnecessary iframes

Step 2: Implement Consent Management for iFrames

If iframes load third-party content that may collect data, ensure they're gated behind consent management. Load iframes conditionally based on user consent.

Consent configuration:

• Identify iframes that may collect user data
• Categorize as requiring consent
• Implement conditional loading based on consent
• Test consent flow to verify blocking
• Monitor iframe loading behavior

Step 3: Use Sandbox and Security Attributes

Apply sandbox attributes and other security measures to iframes to restrict their capabilities and prevent unauthorized access to parent page data.

Security Attributes:

<iframe src="https://example.com"
  sandbox="allow-scripts"
  referrerpolicy="no-referrer"
  loading="lazy">&lt;/iframe&gt;

• Use sandbox to restrict capabilities
• Set referrerpolicy to limit data sharing
• Use loading="lazy" for performance
• Only allow necessary permissions

Step 4: Implement Content Security Policy

Use Content Security Policy headers to control which domains can be embedded as iframes, providing an additional security layer.

CSP implementation:

• Configure frame-src directive
• Whitelist only trusted domains
• Block untrusted iframe sources
• Regularly review and update CSP
• Test CSP to ensure functionality maintained

Step 5: Monitor iFrame Behavior and Data Transmission

Regularly monitor iframe behavior to ensure they're not unexpectedly collecting or transmitting user data. Use browser developer tools and network monitoring.

Monitoring process:

• Use browser developer tools to inspect iframe requests
• Monitor network traffic from iframes
• Check for unexpected data transmission
• Review iframe vendor privacy practices
• Update iframe configurations as needed

Young Domains (31-180 Days)

Reason Code: young-domains

Description: Third-party domains that were registered between 31 and 180 days ago, which may indicate new or potentially risky services

Remediation Steps:

Step 1: Verify Domain Legitimacy and Vendor Reputation

Research the legitimacy of young domains and verify they belong to reputable vendors. Check vendor websites, contact information, and business registration to confirm legitimacy.

Verification process:

• Research domain owner and registration details
• Verify vendor legitimacy and business registration
• Check vendor website and contact information
• Review vendor security practices and certifications
• Contact vendor directly to confirm domain ownership
• Document verification findings

Step 2: Review Vendor Security and Privacy Practices

Conduct a security and privacy assessment of vendors using young domains. Review their security certifications, privacy policies, and data handling practices.

Assessment checklist:

• Review vendor security certifications (SOC 2, ISO 27001, etc.)
• Evaluate vendor privacy policy and data practices
• Check vendor incident response history
• Review vendor compliance certifications
• Assess vendor data processing agreements
• Document assessment findings

Step 3: Monitor Domain Age and Reputation Over Time

Establish monitoring for young domains to track their age and reputation over time. As domains mature and establish reputation, risk may decrease.

Monitoring approach:

• Track domain registration dates
• Monitor domain reputation services
• Set up alerts for domain status changes
• Review domain age periodically
• Update risk assessments as domains mature

Step 4: Implement Additional Security Controls

For young domains, implement additional security controls such as Subresource Integrity (SRI), Content Security Policy restrictions, and enhanced monitoring.

Security controls:

• Implement SRI hashes for resources from young domains
• Use CSP to restrict young domain access
• Enable enhanced logging and monitoring
• Implement rate limiting for young domain requests
• Set up alerts for suspicious activity

Step 5: Consider Alternative Vendors with Established Domains

If young domains pose concerns, consider alternative vendors with more established domain histories and proven track records.

Alternative evaluation:

• Research alternative vendors with established domains
• Compare functionality and features
• Evaluate security and privacy practices
• Assess migration complexity
• Plan migration if alternatives are preferable

First-Party Cookies

Reason Code: 1st_party_cookies

Description: Excessive number of first-party cookies, which can be read by any third-party script and may contain sensitive information accessible across third parties

Remediation Steps:

Step 1: Audit First-Party Cookies and Their Sources

Conduct a comprehensive audit of all first-party cookies to identify which third parties are setting them and what data they contain. Many first-party cookies are actually set by third-party scripts.

Audit process:

• Use browser developer tools to list all first-party cookies
• Identify which third-party scripts are setting first-party cookies
• Document the purpose and data stored in each cookie
• Identify cookies that contain sensitive information
• Categorize cookies by source (first-party vs third-party-set)
• Review cookie expiration times and scope
• Document audit findings and cookie inventory

Step 2: Configure Consent Manager to Delete Unnecessary First-Party Cookies on Opt-Out

Configure your consent management platform to automatically delete first-party cookies that are categorized as unnecessary when users opt out. This provides a clean slate and prevents third parties from reading unnecessary cookies.

CMP Configuration Steps:

1. Access your consent management platform administration panel
2. Navigate to cookie management or cookie deletion settings
3. Configure CMP to scan for first-party cookies on opt-out
4. Set up rules to delete cookies categorized as 'marketing', 'advertising', or 'analytics'
5. Ensure CMP identifies cookies set by third-party scripts
6. Configure CMP to delete cookies immediately when users opt out
7. Test opt-out flow to verify cookies are deleted
8. Verify using browser developer tools that unnecessary cookies are removed
9. Document cookie deletion configuration for future reference

Step 3: Reduce Number of Third Parties to Control Cookie Proliferation

The most effective way to reduce first-party cookies is to reduce the number of third parties on your website. Each third party may set multiple first-party cookies, so fewer third parties means fewer cookies.

Reduction process:

• Conduct audit of all third-party services on your website
• Identify redundant or unnecessary third parties
• Evaluate business value versus privacy impact for each third party
• Remove unnecessary third-party services
• Consolidate functionality where possible (e.g., use one analytics tool instead of multiple)
• Monitor cookie count reduction after removing third parties
• Document third-party removal decisions and business justification

Step 4: Gate Third-Party Scripts Behind Consent to Prevent Cookie Setting

Ensure third-party scripts that set first-party cookies do NOT load at all when users opt out. This prevents third parties from setting cookies in the first place. Use a tag manager as the enforcement layer.

Consent configuration (block scripts entirely):

• Categorize third-party scripts that set cookies as requiring consent in CMP
• If using tag manager (recommended), configure it to block these scripts from loading when users opt out
• Configure CMP to require explicit consent before scripts load
• Ensure opt-out immediately prevents scripts from executing (complete blocking)
• Test using browser Network tab to verify scripts do NOT load when opted out
• Verify that no first-party cookies are set when scripts are blocked
• Test consent flow regularly to verify blocking
• Document consent requirements in privacy policy

Step 5: Review Cookie Security Attributes

Review first-party cookies to ensure they use appropriate security attributes. Use HttpOnly, Secure, and SameSite attributes to limit cookie accessibility and reduce cross-site cookie reading risks.

Cookie Security Attributes:

• HttpOnly: Prevents JavaScript access to cookies (reduces XSS risk)
• Secure: Ensures cookies are only sent over HTTPS
• SameSite: Controls when cookies are sent with cross-site requests
  • Strict: Never send with cross-site requests
  • Lax: Send with top-level navigation
  • None: Always send (requires Secure flag)

Implementation:

• Review cookie settings in your application code
• Configure cookies with appropriate security attributes
• For third-party-set cookies, contact vendors about security attributes
• Test cookie behavior after applying security attributes
• Document cookie security configuration

Step 6: Minimize Sensitive Data in First-Party Cookies

Review first-party cookies to ensure they don't contain sensitive information. If cookies contain sensitive data, consider server-side storage alternatives or encryption.

Data minimization:

• Review cookie contents to identify sensitive data
• Remove sensitive information from cookies (user IDs, email addresses, etc.)
• Use session identifiers instead of storing user data directly
• Consider server-side storage for sensitive data
• Encrypt cookie data if sensitive information must be stored
• Regularly audit cookie contents for sensitive data
• Document cookie data minimization practices

---

Testing Your Remediation

After implementing remediation steps, verify your fixes:

1. Use Browser Developer Tools: Test with Chrome DevTools Network tab to verify scripts are blocked when users opt out
2. Test Consent Flows: Verify consent banners appear and function correctly
3. Check GPC Support: Use browser extensions to test Global Privacy Control signal respect
4. Re-run Assessments: Schedule follow-up privacy assessments to confirm remediation
5. Document Changes: Keep records of remediation steps taken and test results

For detailed testing guidance, see our Testing Consent with Developer Tools guide.

---

Additional Resources

• Web Privacy Quick Start Guide
• Consent Management Platform Best Practices
• Testing Consent with Developer Tools
• Web Privacy Regulations Guide

---

Last Updated: 2025-01-17