# Legal and Compliance Guide

*Audience: legal counsel, privacy/DPO teams, compliance - no technical background required.*

> **Not legal advice.** This document explains how Relyance's Consent Management platform is built and what it lets you configure. It is not a legal opinion on what your organization is required to do in any jurisdiction. Work with your own counsel to determine your specific obligations, and use the configuration guidance described here as a starting point, not a compliance guarantee.

## Why consent management matters

Most global privacy laws that touch cookies and tracking technologies share a common structural requirement: before a website or app processes personal data via a non-essential tracking technology, the operator must (a) give the visitor clear notice, (b) obtain a valid consent decision (or provide a valid opt-out, depending on the legal model), and (c) be able to demonstrate what was decided and when. Relyance Consent Management is built around that three-part structure: **discover** what's actually running, **enforce** the correct consent model per jurisdiction, and **log** every decision as evidence.

## The four consent models

Every Region Group in Relyance is configured with one of four consent models. Region Group configuration is fully customizable, so these models can be applied to meet the legal approaches used across a wide range of regulations - a market-standard, jurisdiction-by-jurisdiction reference for how to configure them is in the [Regional and Jurisdiction Reference](/docs/consent-management/regional-and-jurisdiction-reference/):

| Model | How it behaves | Typically used for |
|---|---|---|
| **Opt-in (explicit consent)** | Non-essential tracking technologies are blocked by default. The visitor must take an affirmative action (e.g., click "Accept") before anything non-essential loads. | GDPR (EU/UK/EEA), LGPD (Brazil), PIPA (South Korea), KVKK (Turkey), nFADP (Switzerland), DPDPA (India) |
| **Opt-out (notice + right to limit)** | Tracking technologies load by default; the visitor is given clear notice and a mechanism to opt out or limit use (e.g., "Do Not Sell or Share My Personal Info"). | US state laws - CCPA/CPRA (California), VCDPA (Virginia), CPA (Colorado), and similar (Utah, Connecticut, Texas, Oregon, Montana) |
| **Implied consent (notice only)** | Tracking technologies load by default; continued use of the site after notice is treated as consent. No blocking, no explicit accept/reject required. | Australia/NZ Privacy Act, Japan (APPI, hybrid), Singapore (PDPA), Canada (PIPEDA, for non-sensitive processing) |
| **No choice** | All processing activities remain active; the visitor is not offered a consent control. | Used sparingly - typically for jurisdictions with no applicable tracking-consent requirement, or for strictly-necessary-only configurations |

Each Region Group also controls three secondary behaviors that carry legal weight in stricter jurisdictions: what happens when a visitor **closes the banner** without choosing, **scrolls**, or **clicks** elsewhere on the page (each can be set to No Action, Deny All, or Accept All). In opt-in jurisdictions like the EU, scrolling or clicking should **not** be treated as consent - that's a well-established regulatory position (guidance from EU data protection authorities has specifically rejected "implied consent by continued browsing" as valid under GDPR) - so market-standard configuration for those regions sets these triggers to No Action. You configure this per Region Group; it isn't preset.

## Global Privacy Control (GPC)

GPC is a browser-level, machine-readable opt-out signal. When a visitor's browser sends a GPC signal, Relyance can automatically treat it as an opt-out request without requiring the visitor to interact with a banner. This matters because **honoring GPC is a binding legal requirement in California (CCPA/CPRA), Colorado (CPA), and Connecticut**. It's not currently a binding requirement in the EU, but several EU data protection authorities have signaled increasing expectations around honoring automated opt-out signals - treat "not required" as "worth checking current guidance," not "safe to skip."

Relyance's GPC handling is configurable per Region Group:
- A master **GPC Integration** toggle turns on signal detection for that region.
- **"Honor GPC for all purposes"** (the recommended default) disables all non-essential tracking the moment a GPC signal is detected - no other visitor action needed.
- **Advanced/per-purpose GPC settings** let you exempt specific purposes from GPC honoring (e.g., a purpose deemed "Strictly Necessary" is always exempt and remains active regardless of GPC). Purposes marked to "Ignore GPC" continue tracking even when the signal is present - this should be a deliberate, counsel-reviewed decision, not a default.

## What gets logged, and why it matters for defensibility

When consent logging is enabled for a domain, Relyance records a structured event for every consent decision, including: a device or user identifier, timestamp, the visitor's detected region, IP address, browser/user-agent information, GPC signal status, and the accept/reject state of every individual purpose (not just an "accepted all" flag). This is the evidentiary backbone for demonstrating compliance - see [Consent Logs and Reporting](/docs/consent-management/consent-logs-and-reporting/) for the full schema and export process.

**Data minimization controls.** Because the consent log itself processes personal data (IP address, user agent), Relyance provides opt-in minimization settings at the point logging is configured:
- **Anonymize IP addresses** - strips the last octet before storage, reducing precision while preserving enough for regional/audit purposes.
- **Store browser type only** - stores a normalized browser identifier instead of the full user-agent string, which can otherwise be highly identifying.

We recommend enabling both for any domain subject to GDPR-style data minimization obligations, and evaluating them against your own retention policy for other jurisdictions.

## Authenticated Consent and record integrity

For logged-in experiences, Relyance can tie a visitor's consent decision to an authenticated user identifier your engineering team supplies at login, rather than only a browser/device. This has two compliance benefits: it prevents a fragmented consent history across a user's devices, and it strengthens your audit trail by tying a decision to an identifiable account rather than an anonymous device ID. Your organization controls what identifier is used (e.g., a UUID vs. an email address) - choose based on your own data-minimization posture, since that value is itself stored for audit purposes. See the [Technical Implementation Guide](/docs/consent-management/technical-implementation-guide/#11-authenticated-consent-and-cross-device-sync) for the implementation details your engineering team will need.

## Default/fallback jurisdiction handling

Every domain has a **Global** Region Group that cannot be deleted - it's the fallback applied to any visitor whose jurisdiction isn't explicitly covered by a more specific Region Group. See the [Regional and Jurisdiction Reference](/docs/consent-management/regional-and-jurisdiction-reference/) for the market-standard fallback pattern and how to adapt it to your own risk posture.

## Related reading

- [Regional and Jurisdiction Reference](/docs/consent-management/regional-and-jurisdiction-reference/) - the full per-jurisdiction market-standards configuration reference
- [Admin Configuration Guide](/docs/consent-management/admin-configuration-guide/#consent-domain-behavior-configuration-region-groups) - how to actually configure Region Groups and GPC in the platform
- [Consent Logs and Reporting](/docs/consent-management/consent-logs-and-reporting/) - exporting logs for audits, DSARs, or regulator requests
- [FAQ: Consent Management](/docs/consent-management/faq-consent-management/) - common questions from prospects and new customers