Loading auth config...
Skip to main content
Lokker
A visual representation of testing consent management with browser developer tools, highlighting key concepts and processes related to the topic.

Testing Consent Management with Browser Developer Tools

As an engineer working with consent management platforms (CMPs) like OneTrust, Cookiebot, or others, you need practical ways to verify that consent rules are working correctly. This guide shows you how to use browser developer tools to test consent implementations, spot-check rule changes, and ensure your tag manager and consent management tool are working together properly.

Table of Contents​

Why Manual Testing Matters​

Automated testing tools are valuable, but manual testing with browser developer tools gives you real-time visibility into:

  • What third-party requests are actually being made
  • When requests occur (before or after consent)
  • What data is being sent in request payloads
  • Which scripts initiated the requests (initiator chains)
  • Whether consent rules are being respected after opt-out

This hands-on approach helps you catch issues that automated tests might miss, especially when testing consent management platform updates or tag manager configuration changes.

⚠️ Important: Understand Your Applicable Regulations​

Before testing, know which privacy regulations apply to your website:

  • GDPR (Europe) - Requires opt-in consent before tracking
  • CCPA/CPRA (California) - Allows default tracking, requires opt-out mechanism
  • Other US State Laws - Vary in opt-in vs. opt-out requirements
  • Other Regional Laws - Each has specific consent requirements

What you're testing for depends on your regulations:

  • In opt-in regions (GDPR), tracking before consent is a violation
  • In opt-out regions (CCPA), tracking before consent may be permitted, but opt-out must be honored

Throughout this guide, we'll note regional differences so you can test according to your applicable regulations.

Setting Up Your Testing Environment​

⚠️ Critical: Use Chrome Guest Profile for Clean Testing​

Before you start testing, use Chrome Guest Profile to avoid false results from browser extensions.

Why Guest Profile is Essential​

Many developers have browser extensions installed that can interfere with consent testing:

  • uBlock Origin - Blocks third-party scripts and tracking
  • Privacy Badger - Automatically blocks trackers
  • AdBlock Plus - Blocks ads and tracking scripts
  • Ghostery - Blocks tracking scripts
  • Other privacy extensions - Various blockers that prevent third-party requests

The Problem: These extensions can give you false confidence that your consent management is working correctly. When you see no third-party requests, it might be because:

  • ✅ Your consent rules are working (correct)
  • ❌ Your browser extension is blocking them (incorrect - gives false hope)

How to Use Chrome Guest Profile​

  1. Open Chrome

  2. Click your profile icon (top right corner)

  3. Select "Guest" from the profile menu

  4. A new Guest window opens - This is a completely clean browser:

    • No extensions installed
    • No cookies or browsing history
    • No saved passwords or data
    • Clean slate for testing

  5. Navigate to your website in the Guest window

  6. Open DevTools (F12) and proceed with testing

Benefits of Guest Profile:

  • ✅ No extension interference
  • ✅ No previous cookies or consent data
  • ✅ Clean browser state every time
  • ✅ Accurate test results

Alternative: If you must use your regular profile, disable all extensions temporarily:

  1. Go to chrome://extensions/
  2. Toggle off all extensions
  3. Reload your test page

However, Guest Profile is strongly recommended for the most accurate testing.

Step 1: Open Chrome Developer Tools​

  1. In your Guest Profile window, navigate to your website
  2. Press F12 or right-click and select "Inspect"
  3. Open the Network tab - This is where you'll monitor all network requests

Step 2: Clear Existing Data (Important for Testing)​

Before testing consent, you need a clean slate:

  1. Open Application tab (next to Network tab)

  2. Clear Storage:

    • Click "Clear site data" button, OR
    • Manually delete:
      • Cookies → Your domain → Delete all
      • Local Storage → Your domain → Delete all
      • Session Storage → Your domain → Delete all

  3. Refresh the page - You should now see the consent banner again

Step 3: Enable Network Recording​

  1. Go back to Network tab
  2. Check "Preserve log" - This keeps requests visible after page refreshes
  3. Clear the network log (trash icon) to start fresh

⚠️ Critical Warning: "Preserve log" Can Cause Confusion​

Important: While "Preserve log" is useful for seeing requests across page refreshes, it can also mislead you if you're not careful:

The Problem:

  • When you enable "Preserve log" and refresh the page after making a consent choice, old requests from before the refresh remain visible
  • You might see tracking requests that you think are happening after opt-out, but they're actually from before the refresh
  • This can make you think consent rules aren't working when they actually are

How to Avoid This:

  1. Always clear the network log (trash icon) after each page refresh when testing consent
  2. Only look at requests that appear AFTER the refresh - ignore anything from before
  3. Use timestamps - Check the "Time" column to see when requests occurred relative to the page refresh
  4. Alternative: Don't use "Preserve log" - just reload and check the fresh network log each time

Best Practice: Clear the network log → Make consent choice → Page refreshes → Check only the NEW requests that appear after refresh

Monitoring Third-Party Network Traffic​

Understanding Third-Party Requests​

Third-party requests are network calls to domains other than your website. Common examples include:

  • www.google-analytics.com - Google Analytics
  • www.facebook.com - Meta Pixel
  • cdn.cookielaw.org - Cookiebot
  • cdn.cookielaw.org - OneTrust
  • www.googletagmanager.com - Google Tag Manager
  • analytics.twitter.com - Twitter Pixel

Viewing All Network Requests​

  1. Open Network tab in DevTools
  2. Reload the page (Ctrl+R or Cmd+R)
  3. Watch the requests populate in real-time

You'll see:

  • Request name (the endpoint being called)
  • Status (200, 404, etc.)
  • Type (document, script, xhr, etc.)
  • Size (how much data transferred)
  • Time (how long the request took)

Filtering Network Requests​

Filter by Domain (Third-Party Detection)​

To see only third-party requests:

  1. Click the filter icon (funnel) in Network tab
  2. Select "Domain" filter
  3. Enter a domain like google-analytics.com or facebook.com

Pro Tip: Use negative filters to exclude your domain:

  • Type -yourdomain.com to hide your own domain's requests
  • This makes third-party requests easier to spot

Filter by Request Type​

Filter by specific request types:

  • -document - Hide page loads, show only resources
  • xhr - Show only AJAX/fetch requests (often where tracking data is sent)
  • script - Show only JavaScript files
  • img - Show only image requests (tracking pixels)

Filter by URL Pattern​

Use the search box to filter by URL patterns:

  • analytics - Find all analytics-related requests
  • pixel - Find tracking pixel requests
  • collect - Google Analytics collection endpoints
  • onetrust or cookielaw - Consent management platform requests

Combining Filters​

You can combine multiple filters:

-domain:yourdomain.com xhr

This shows only XHR requests that are NOT from your domain (third-party tracking).

Reviewing Request Payloads and Initiators​

Viewing Request Payloads​

To see what data is being sent to third parties:

  1. Click on a network request in the list

  2. Open the "Payload" tab (or "Request" tab)

  3. Review the data being sent:

    • Query parameters - Data in the URL
    • Request headers - Headers sent with the request
    • Request payload - Body data (for POST requests)

Example: A Google Analytics request might show:

v=2&tid=UA-123456-1&cid=123.456&t=pageview&dp=%2Fhome

This tells you:

  • tid = Tracking ID
  • cid = Client ID (user identifier)
  • t = Hit type (pageview, event, etc.)
  • dp = Document path

Understanding Initiator Chains​

The initiator chain shows which script triggered a network request:

  1. Click on a network request
  2. Open the "Initiator" tab
  3. View the call stack - Shows the chain of scripts that led to this request

Why This Matters:

index.html
  └── gtm.js (Google Tag Manager)
      └── ga.js (Google Analytics)
          └── collect request (tracking call)

This tells you:

  • GTM loaded Google Analytics
  • GA script made the tracking request
  • You can verify if consent rules prevented GTM from loading GA

Checking Request Timing​

  1. Click on a request

  2. Open the "Timing" tab

  3. Review when the request occurred:

    • Before consent banner interaction? → Depends on regulations (see Regional Context below)
    • After consent accepted? → Expected behavior
    • After consent rejected? → Should NOT happen (violation in all regions)

⚠️ Important: Regional Regulatory Differences​

What constitutes a "red flag" depends on which regulations apply to your website:

Europe (GDPR) - Opt-In Required:

  • ❌ Tracking requests before consent = Violation
  • ✅ Tracking only allowed after explicit consent
  • ✅ Must show consent banner before any non-essential tracking

United States (CCPA/CPRA) - Opt-Out Model:

  • ✅ Tracking can occur by default before consent interaction
  • ✅ Must provide "Do Not Sell/Share" opt-out mechanism
  • ❌ Tracking after opt-out = Violation
  • ✅ Must honor opt-out requests immediately

California (CPRA) - Enhanced Requirements:

  • ✅ Default opt-out for certain sensitive data categories
  • ✅ Must honor Global Privacy Control signals
  • ❌ Tracking sensitive categories without consent = Violation

Key Point: Understand which regulations apply to your website based on:

  • Where your users are located
  • Where your business operates
  • What data you collect

When testing, verify your implementation matches the opt-in vs. opt-out requirements for your applicable regulations.

Scenario: Testing OneTrust Update​

After updating OneTrust configuration, verify the changes work:

  1. Clear all cookies and storage (Application tab → Clear site data)
  2. Open Network tab with "Preserve log" enabled
  3. Clear the network log (trash icon) to start fresh
  4. Reload page - Consent banner should appear
  5. Note which requests occur before interacting with banner
  6. Take a screenshot or note the request list

Step 2: Accept All Test​

  1. Click "Accept All" in consent banner
  2. Page should refresh (if implemented correctly)
  3. ⚠️ CRITICAL: Clear the network log (trash icon) immediately after refresh
    • This removes old requests from before consent
    • You only want to see requests that happen AFTER consent was accepted
  4. Check Network tab - Which third-party requests now appear?
  5. Verify expected tags fire:
    • Google Analytics should load
    • Marketing pixels should fire
    • Expected tracking scripts should execute

⚠️ Don't Fall Into This Trap: If you don't clear the log after refresh, you'll see old requests mixed with new ones and might incorrectly think tags are firing when they're not.

Step 3: Reject All Test​

  1. Clear cookies/storage again
  2. Reload page - Consent banner appears
  3. Clear the network log (trash icon) before clicking reject
  4. Click "Reject All"
  5. Page refreshes
  6. ⚠️ CRITICAL: Clear the network log again (trash icon) immediately after refresh
    • This ensures you only see requests from AFTER the opt-out
    • Old requests from before opt-out will confuse you
  7. Check Network tab - Which requests should NOT appear:
    • Marketing pixels should be blocked
    • Analytics might be blocked (depending on configuration)
    • Only essential/functional cookies should load

⚠️ Common Mistake: Seeing tracking requests after "Reject All" and thinking consent isn't working, when actually those are old requests from before the refresh. Always clear the log after refresh!

Step 4: Verify Rule Application​

Compare the request lists:

ScenarioExpected Behavior
Before consentDepends on regulations (see Regional Context)
Accept AllAll configured tags should fire
Reject AllOnly essential tags, marketing blocked

Red Flags (Universal - Apply to All Regions):

  • ❌ Marketing pixels firing after "Reject All" or opt-out
  • ❌ Analytics firing when user opted out of analytics
  • ❌ Tracking continuing after explicit opt-out request

Regional Red Flags:

Europe (GDPR) - Opt-In Required:

  • ❌ Any tracking requests before consent banner interaction (except essential/functional)
  • ❌ Non-essential cookies/tracking before explicit consent

United States (CCPA/CPRA) - Opt-Out Model:

  • ✅ Tracking before consent interaction is permitted (default opt-out)
  • ❌ Tracking after opt-out request = Violation
  • ❌ Not honoring "Do Not Sell/Share" requests

Important: Know which regulations apply to your website and test accordingly. A "red flag" in Europe may be expected behavior in the US, and vice versa.

Verifying Tag Manager Integration​

Testing GTM + OneTrust Integration​

When Google Tag Manager is integrated with OneTrust, verify they work together:

  1. Open Console tab in DevTools
  2. Type: dataLayer
  3. Press Enter - View the dataLayer array
  4. Look for consent events:
{
  event: "OneTrustGroupsUpdated",
  OneTrustActiveGroups: "C0001,C0002"
}

This shows:

  • Which consent groups are active
  • Whether GTM received consent updates
  • If consent state is being passed correctly

Step 2: Verify Tag Firing Rules​

  1. Open Network tab
  2. Filter for GTM requests: googletagmanager.com
  3. After consent choice:
    • Check if GTM container loads
    • Verify tags fire based on consent groups
    • Confirm blocked tags don't fire

Step 3: Check Tag Manager Preview Mode​

  1. Install GTM Preview extension (Chrome extension)
  2. Open GTM Preview and connect to your site
  3. View tag firing:
    • See which tags fired
    • See which tags were blocked
    • Verify consent conditions are evaluated

What to Look For:

  • Tags with consent triggers should fire when consent given
  • Tags with consent triggers should NOT fire when consent denied
  • Consent state should be available in tag conditions

Resetting Cookies and Local Storage​

Why You Need to Reset​

Consent preferences are stored in:

  • Cookies - Consent choices (e.g., OptanonConsent)
  • Local Storage - Additional consent data
  • Session Storage - Temporary consent state

To test consent flows properly, you need to clear these.

The easiest and most reliable method - Use Chrome Guest Profile (see setup section above):

  1. Open Chrome Guest Profile (Profile icon → Guest)
  2. Navigate to your website
  3. No cookies, no storage, no extensions - Perfect clean slate
  4. Test consent flows - Consent banner will appear fresh every time

Why This is Best:

  • ✅ No manual clearing needed
  • ✅ No extension interference
  • ✅ Completely clean state every time
  • ✅ Most accurate test results

Method 2: Clear Site Data (Manual Method)​

  1. Open Application tab
  2. Click "Clear site data" button
  3. Check all boxes:
    • Cookies and other site data
    • Cached images and files
    • Local storage
  4. Click "Clear data"
  5. Refresh page - Consent banner should reappear

Method 3: Clear Specific Cookies​

  1. Open Application tab → Cookies
  2. Select your domain
  3. Find consent-related cookies:
    • OptanonConsent (OneTrust)
    • CookieConsent (Cookiebot)
    • OptanonAlertBoxClosed (OneTrust)
  4. Right-click → Delete on each cookie
  5. Refresh page

Method 4: Clear Local Storage​

  1. Open Application tab → Local Storage
  2. Select your domain
  3. Right-click → Clear or delete specific keys
  4. Refresh page

Method 5: Use Incognito Mode​

For clean testing (though Guest Profile is preferred):

  1. Open Incognito/Private window (Ctrl+Shift+N)
  2. Navigate to your site
  3. Consent banner should appear (no previous consent data)
  4. Test consent flows

Note: Incognito mode still loads your browser extensions, which can interfere with testing. Guest Profile is recommended for the most accurate results without extension interference.

Common Testing Scenarios​

Scenario 1: Testing After OneTrust Configuration Update​

Goal: Verify new consent rules are applied

Steps:

  1. Clear all site data
  2. Open Network tab with "Preserve log" enabled
  3. Clear the network log (trash icon) to start fresh
  4. Reload page → Note baseline requests
  5. Accept consent → Page refreshes
  6. ⚠️ Clear the network log immediately after refresh - Only check NEW requests
  7. Verify expected tags fire (from requests after refresh only)
  8. Clear data again
  9. Reload page → Clear network log
  10. Reject consent → Page refreshes
  11. ⚠️ Clear the network log immediately after refresh - Only check NEW requests
  12. Verify unwanted tags are blocked (check only requests after refresh)
  13. Compare against expected behavior from your OneTrust configuration

⚠️ Critical: Always clear the network log after each page refresh. Old requests will make you think consent isn't working when it actually is.

Scenario 2: Testing Tag Manager Rule Changes​

Goal: Verify GTM tags respect consent

Steps:

  1. Open GTM Preview mode
  2. Clear site data and reload
  3. Accept consent → Check which tags fire in GTM Preview
  4. Note the tags that fired
  5. Clear data and reload
  6. Reject consent → Verify those same tags DON'T fire
  7. Check Network tab to confirm no third-party requests

Scenario 3: Testing Page Refresh Requirement​

Goal: Verify page refresh happens after consent choice

Steps:

  1. Open Network tab with "Preserve log" enabled
  2. Clear the network log (trash icon) to start fresh
  3. Reload page → Consent banner appears
  4. Note requests before consent interaction
  5. Click "Accept All"
  6. Check if page refreshes:
    • Network log should show new page load
    • "Preserve log" keeps old requests visible
  7. ⚠️ CRITICAL: Clear the network log immediately after refresh
    • This removes requests from before consent
    • You only want to analyze requests that happen AFTER consent
  8. After refresh: Verify new requests match consent choice
    • Only look at requests that appear AFTER the refresh
    • Ignore any requests that were there before the refresh

Red Flag: If page doesn't refresh, tracking scripts from before consent may still be active.

⚠️ Common Mistake: Not clearing the log after refresh, then seeing old tracking requests and incorrectly thinking consent isn't working. Always clear the log after refresh!

Note: In GDPR regions, tracking before consent is a violation. In CCPA/CPRA regions, tracking before consent interaction may be permitted, but you must honor opt-out requests immediately.

Scenario 4: Testing Specific Third-Party Services​

Goal: Verify a specific service (e.g., Meta Pixel) respects consent

Steps:

  1. Filter Network tab: facebook.com or fbcdn.net
  2. Clear site data and reload
  3. Before consent:
    • GDPR (Europe): Should see NO Facebook requests (opt-in required)
    • CCPA/CPRA (US): May see Facebook requests (opt-out model allows default tracking)
    • Verify based on your applicable regulations
  4. Accept consent → Should see Facebook Pixel requests
  5. Clear data and reload
  6. Reject consent/opt-out → Should see NO Facebook requests (universal requirement)

Troubleshooting Tips​

Possible Causes:

  • Cookies/localStorage not cleared properly
  • Consent banner script not loading
  • Ad blocker blocking consent platform

Solution:

  1. Check Network tab for consent platform requests (OneTrust, Cookiebot, etc.)
  2. Verify script loads without errors
  3. Check Console tab for JavaScript errors
  4. Try Incognito mode to rule out extensions

Issue: Tags Still Firing After Reject​

Possible Causes:

  • "Preserve log" showing old requests from before page refresh (most common mistake)
  • Page refresh not happening after consent choice
  • Tag Manager not receiving consent updates
  • Consent rules not configured correctly in CMP

Solution:

  1. ⚠️ First: Clear the network log (trash icon) immediately after page refresh
    • Old requests from before opt-out will confuse you
    • Only check requests that appear AFTER the refresh
  2. Verify page refreshes after consent choice (check Network tab for new document request)
  3. Check Console for dataLayer consent events
  4. Verify OneTrust/GTM integration is configured
  5. Check GTM Preview mode to see tag firing conditions

⚠️ Most Common Mistake: Seeing tracking requests after "Reject All" and thinking consent isn't working, when actually those are old requests from before the page refresh. Always clear the network log after refresh!

Issue: Can't See Third-Party Requests​

Possible Causes:

  • Requests blocked by browser extension (uBlock Origin, Privacy Badger, etc.)
  • Requests blocked by ad blocker
  • Requests happening too fast to catch
  • Filter settings hiding requests

Solution:

  1. Use Chrome Guest Profile - This eliminates extension interference (recommended)
  2. If using regular profile, disable all extensions at chrome://extensions/
  3. Use "Preserve log" to keep requests visible (but see warning below)
  4. Clear filters and search for specific domains
  5. Check "Disable cache" to see all requests

Important: If you're not seeing third-party requests, check if your browser extensions are blocking them before assuming your consent management is working correctly.

Issue: Seeing Tracking Requests After Opt-Out (False Positive)​

Possible Causes:

  • "Preserve log" showing old requests from before page refresh (most common)
  • Page refresh not happening after consent choice
  • Consent rules not configured correctly

Solution:

  1. ⚠️ Always clear the network log (trash icon) immediately after page refresh
  2. Only analyze requests that appear AFTER the refresh - ignore anything from before
  3. Check the "Time" column to see when requests occurred relative to page refresh
  4. Verify page actually refreshed (look for new document request in Network tab)
  5. If page didn't refresh, that's the real problem - fix the page refresh implementation

Common Mistake: Using "Preserve log" and seeing old tracking requests from before opt-out, then incorrectly thinking consent isn't working. The requests you see might be from BEFORE the refresh, not after. Always clear the log after refresh!

Issue: Initiator Chain Not Showing​

Possible Causes:

  • Request from cached resource
  • Request from extension
  • Request from service worker

Solution:

  1. Check "Disable cache" in Network tab
  2. Disable extensions temporarily
  3. Check Service Workers in Application tab
  4. Look at "Request" tab for more details

Possible Causes:

  • LocalStorage/cookies not updating
  • CMP script error
  • Integration issue with tag manager

Solution:

  1. Check Application tab → Local Storage for consent keys
  2. Check Console for JavaScript errors
  3. Verify CMP script version is correct
  4. Check Network tab for CMP API calls failing

Best Practices for Testing​

1. Always Use Chrome Guest Profile​

Critical: Always start testing in Chrome Guest Profile to avoid false results from browser extensions:

  • ✅ No extension interference
  • ✅ Clean browser state
  • ✅ Accurate test results
  • ✅ No false confidence from extension blockers

Only use your regular browser profile if you've verified all extensions are disabled.

1.5. Always Clear Network Log After Page Refresh​

Critical: When using "Preserve log" to test consent, always clear the network log immediately after each page refresh:

  • ✅ Removes old requests from before consent choice
  • ✅ Only shows requests that happen AFTER consent
  • ✅ Prevents false positives (thinking consent isn't working)
  • ✅ Accurate analysis of what's actually happening

The Trap: "Preserve log" keeps old requests visible. After clicking "Reject All" and the page refreshes, you'll see old tracking requests mixed with new ones. If you don't clear the log, you'll incorrectly think tracking is still happening when it's actually been stopped.

Best Practice: Clear log → Make consent choice → Page refreshes → Clear log again → Only analyze NEW requests

2. Test in Multiple Browsers​

Different browsers may handle consent differently:

  • Test in Chrome, Firefox, Safari, Edge
  • Check if consent preferences persist across browsers
  • Verify third-party blocking works consistently

3. Test on Different Devices​

  • Desktop browsers
  • Mobile browsers (Chrome DevTools → Device toolbar)
  • Different screen sizes

4. Document Your Findings​

When testing consent implementations:

  • Screenshot Network tab before/after consent
  • Note which requests should/shouldn't appear
  • Document any unexpected behavior
  • Create a testing checklist for your team

5. Test Regularly​

Consent management requires ongoing verification:

  • After CMP updates - Verify rules still work
  • After tag manager changes - Verify tags respect consent
  • After code deployments - Verify nothing broke
  • Periodic audits - Ensure compliance maintained

6. Use Browser Extensions (Carefully)​

Important: Only use extensions in Guest Profile after installing them, or disable privacy extensions when testing:

Helpful extensions for consent testing:

  • GTM Preview - See tag firing in real-time (install in Guest Profile if needed)
  • OneTrust Cookie Scanner - View cookie categories

Avoid during testing:

  • uBlock Origin - Blocks third-party requests (interferes with testing)
  • Privacy Badger - Blocks trackers (interferes with testing)
  • Ghostery - Blocks tracking scripts (interferes with testing)

These privacy extensions can give false confidence that consent management is working when they're actually blocking requests.

Quick Reference Checklist​

Use this checklist when testing consent implementations:

Pre-Testing Setup​

  • Open Chrome Guest Profile (Profile icon → Guest) - Critical for accurate testing
  • Open Chrome DevTools (F12) in Guest Profile window
  • Enable "Preserve log" in Network tab
  • Clear network log (trash icon) to start fresh

Testing Accept All​

  • Reload page → Consent banner appears
  • Note requests before consent interaction
  • Click "Accept All"
  • Verify page refreshes
  • ⚠️ CRITICAL: Clear network log immediately after refresh
  • Check Network tab → Expected tags should fire (only NEW requests after refresh)
  • Verify third-party requests match consent choice

Testing Reject All​

  • Clear site data again
  • Reload page → Consent banner appears
  • Clear network log before clicking reject
  • Click "Reject All"
  • Verify page refreshes
  • ⚠️ CRITICAL: Clear network log immediately after refresh
  • Check Network tab → Marketing tags should NOT fire (only check NEW requests)
  • Verify only essential requests occur

⚠️ Remember: Always clear the network log after each page refresh. "Preserve log" keeps old requests visible, which can make you think consent isn't working when it actually is.

Verifying Integration​

  • Check Console → dataLayer shows consent events
  • Verify GTM Preview shows correct tag firing
  • Confirm consent state in Local Storage
  • Test that consent persists across page navigations

Remember: Manual testing with developer tools gives you real-time visibility into what's actually happening on your website. Use these tools regularly to verify consent management is working correctly and catch issues before they become compliance problems.