Home > Docs > Best Practices > Security > CCPA / CPRA Privacy Rights

🛡️ CCPA / CPRA Privacy Rights Implementation on Microsoft Fabric¶

Last Updated: 2026-04-27 | Version: 1.0.0 | Wave 5 Feature: 5.4 | Anchor: SOC 2 Type II

Disclaimer: This document provides architectural and technical guidance for implementing CCPA and CPRA consumer privacy rights on Microsoft Fabric. It is not legal advice. CCPA/CPRA enforcement is delegated to the California Privacy Protection Agency (CPPA) and California Attorney General; their interpretations evolve. Engage qualified privacy counsel to validate your compliance program. Verify all definitions, thresholds, and timing requirements with current California statute and CPPA regulations before relying on them in production.

📑 Table of Contents¶

• 🎯 Overview
• 📋 CCPA vs GDPR
• ⚖️ The Seven CCPA Consumer Rights
• 🚫 Do Not Sell or Share
• 🔐 Sensitive Personal Information (SPI)
• 🏗️ Fabric Implementation
• 📨 DSAR Workflow
• 📋 Categories Disclosure Requirements
• 🚦 GPC and Opt-Out Implementation
• 🛡️ SPI Limitation Implementation
• 🤝 Service Provider vs Third Party
• 💰 Pricing & Non-Discrimination
• 🎰 Casino Implementation
• 🏛️ Federal & Multi-State Implementation
• 🌍 Doing Both CCPA and GDPR
• 🚫 Anti-Patterns
• 📋 Implementation Checklist
• 📚 References

🎯 Overview¶

The California Consumer Privacy Act (CCPA) of 2018, as amended by the California Privacy Rights Act (CPRA) effective January 1, 2023, is the most prescriptive U.S. state privacy regime. Unlike GDPR — which is built on lawful-basis-for-processing — CCPA centers on disclosure, opt-out, and consumer rights. Both regimes give individuals control over personal information, but the mechanics differ enough that you cannot simply repurpose a GDPR program for California compliance.

Scope: Who Must Comply¶

A "business" is subject to CCPA/CPRA if it does business in California, collects (or has collected on its behalf) personal information of California residents, determines purposes/means of processing, and meets at least one of:

Special considerations:

• Service providers and contractors inherit obligations through their service agreement (CCPA-required contract terms).
• B2B exemption sunset: CPRA removed the temporary B2B and employee exemptions effective January 1, 2023 — employees, applicants, and B2B contacts are now full "consumers" with rights.
• Non-profits are generally out of scope unless controlled by a covered for-profit business.
• HIPAA-covered entities may be partially exempt for PHI, but non-PHI consumer data is in scope.
• GLBA / FCRA preempt for data already covered, but residual data falls under CCPA.

What This Document Covers¶

• The seven consumer rights (four original CCPA + three CPRA additions) and how each is implemented in Fabric
• The unique "Do Not Sell or Share" opt-out — including Global Privacy Control (GPC) signal handling
• Sensitive Personal Information (SPI) handling and the "right to limit"
• Data subject access request (DSAR) workflow with 45-day verification + response timing
• Service Provider vs Third Party distinction and contract management
• Multi-state coexistence (CCPA + Virginia VCDPA + Colorado CPA + Connecticut CTDPA + Utah UCPA + Texas TDPSA)
• Coexistence with GDPR (the "stricter rule wins" pattern)

📝 Scope: This is the CCPA/CPRA implementation deep-dive for Phase 14 Wave 5. For the privacy-by-deletion mirror in EU/UK, see GDPR Right to Deletion. For the Trust Services Criteria mapping that includes Privacy TSC, see the SOC 2 anchor. For data classification and labeling patterns these rights depend on, see Data Governance Deep Dive.

📋 CCPA vs GDPR¶

The single largest mistake in U.S. privacy programs is treating CCPA as "GDPR-lite." It is not. The regimes overlap substantially, but the mental models differ.

⚠️ The biggest practical difference: CCPA assumes you collect first and let consumers opt out. GDPR assumes you must justify each collection upfront. Your Fabric pipelines must support both mental models: tag every record with lawful basis (GDPR) AND opt-out flags (CCPA).

⚖️ The Seven CCPA Consumer Rights¶

CPRA (effective 2023) added three new rights on top of the four original CCPA rights, for a total of seven.

1. Right to Know (CCPA original)¶

Consumers can request that a business disclose:

Default lookback: 12 months. CPRA: consumers can request data beyond 12 months (back to January 1, 2022) unless disproportionately burdensome.

2. Right to Delete (CCPA original)¶

Consumers can request deletion. Exceptions are broad:

• Complete the transaction; provide the requested service
• Detect security incidents; protect against fraud
• Debug to identify and repair errors
• Exercise free speech (yours or another consumer's)
• Comply with legal obligations
• Internal uses reasonably aligned with consumer expectations
• Other internal lawful uses compatible with the context of collection

The "internal use" exception is broader than GDPR Article 17's exceptions. Document the specific exception when refusing a delete request.

3. Right to Correct (CPRA addition)¶

Consumers can request correction of inaccurate PI. Business must use commercially reasonable efforts to correct. Mirrors GDPR Article 16.

4. Right to Opt-Out of Sale (CCPA original)¶

Consumers can direct a business not to "sell" their PI. (See Do Not Sell or Share below — "sell" is broader than money exchange.)

5. Right to Opt-Out of Sharing for Cross-Context Behavioral Advertising (CPRA addition)¶

CPRA introduced "share" as a separate concept covering data transfers to third parties for cross-context behavioral advertising (i.e., retargeting based on activity across non-affiliated sites). Even if no money changes hands, this disclosure is opt-outable.

6. Right to Limit Use of Sensitive Personal Information (CPRA addition)¶

When a business uses SPI for purposes beyond providing the requested goods/services, consumers can require the business to limit SPI use to the minimum necessary. See SPI below.

7. Right to Non-Discrimination (CCPA original)¶

Businesses cannot deny goods/services, charge different prices, provide different quality, or threaten any of the above for exercising rights — except where the difference is reasonably related to the value provided by the consumer's data. Loyalty programs are permissible if the structure satisfies the financial-incentive notice requirements (CPRA §1798.125).

🚫 Do Not Sell or Share¶

The single most operationally distinct CCPA concept. Get this wrong and the AG will notice.

The "Sale" Definition (Broad)¶

Under CCPA, a "sale" is any transfer of PI to a third party for monetary or other valuable consideration. This is far broader than literal money exchange. Examples that have been treated as "sales":

• Sharing email lists with a marketing partner in exchange for analytics access
• Allowing an advertising SDK to collect device identifiers in exchange for an ad placement
• Disclosing visitor data to a "data co-op" for mutual benefit

Not a sale (CCPA exemptions):

• Disclosure to a service provider under a CCPA-compliant service agreement (with required contract terms)
• Disclosure at the consumer's direction
• Sharing among a controlled group of entities under a single brand
• Disclosure of de-identified or aggregate consumer information

The "Share" Definition (CPRA Addition)¶

"Share" means disclosing PI to a third party for cross-context behavioral advertising, whether or not for monetary consideration. CPRA created this category specifically to capture pixel-tag and SDK data flows that AdTech vendors had argued were not "sales."

Implementation: Three Required Mechanisms¶

Consequences of Opt-Out¶

When a consumer opts out:

• Stop selling/sharing their PI to third parties within 15 business days
• Notify all third parties to whom the data was sold/shared in the prior 90 days
• Maintain the opt-out for 12 months minimum before asking again
• Service providers continue to receive data (they are not third parties)

Pipeline Implications¶

Bronze ingestion captures opt-out events. Silver and Gold pipelines that produce data feeding ad networks, analytics co-ops, or third-party marketing destinations must filter on opt_out_sale = true and opt_out_share = true. See Fabric Implementation below.

🔐 Sensitive Personal Information (SPI)¶

CPRA introduced Sensitive Personal Information as a sub-category requiring elevated handling.

Categories of SPI¶

Right to Limit Use of SPI¶

When a consumer invokes the right to limit, the business may only use SPI for:

• Performing the services or providing the goods reasonably expected
• Detecting security incidents; resisting malicious activity
• Short-term, transient use including non-personalized advertising
• Performing services on behalf of the business (logging, fulfillment)
• Verifying or maintaining quality / safety of services

Anything beyond — including profiling, model training on SPI, or marketing — must stop within 15 business days of the request.

Fabric Implementation¶

🏗️ Fabric Implementation¶

The technical core: a single consent registry, gating filters in Silver, and audit evidence in Bronze.

Consumer Consent Registry¶

A single canonical table in Silver tracks every California consumer's consent state.

-- lh_silver.consumer_consent (Delta table, schema-enforced)
CREATE TABLE IF NOT EXISTS lh_silver.consumer_consent (
    subject_id              STRING NOT NULL,    -- canonical consumer ID
    jurisdiction            STRING NOT NULL,    -- 'CA-CCPA', 'EU-GDPR', etc.
    consent_status          STRING NOT NULL,    -- 'active', 'withdrawn', 'pending'
    opt_out_sale            BOOLEAN NOT NULL,   -- §1798.120 right to opt-out of sale
    opt_out_share           BOOLEAN NOT NULL,   -- §1798.120 (CPRA) opt-out of sharing
    limit_spi_use           BOOLEAN NOT NULL,   -- §1798.121 right to limit SPI
    gpc_signal_seen         BOOLEAN NOT NULL,   -- Global Privacy Control header detected
    delete_requested_at     TIMESTAMP,          -- §1798.105 right to delete
    correction_requested_at TIMESTAMP,          -- §1798.106 right to correct (CPRA)
    last_updated            TIMESTAMP NOT NULL,
    source_system           STRING NOT NULL,    -- 'cmp', 'webform', 'gpc', 'agent'
    verification_method     STRING,             -- DSAR verification record
    cure_period_until       TIMESTAMP           -- if remediation in progress
)
USING DELTA
PARTITIONED BY (jurisdiction);

Schema notes:

• jurisdiction allows multi-regime tracking (CA, EU, NY, etc.) without separate tables.
• gpc_signal_seen is separately tracked because GPC is presumed equivalent to opt-out under CPPA regulations — auditors will ask.
• cure_period_until records the 45-day window granted by the AG/CPPA before enforcement.
• Partition by jurisdiction to keep query plans tight.

Consent Gating in Pipelines¶

Every Silver and Gold notebook that produces data for downstream sale/sharing must join against the consent registry and filter.

from pyspark.sql import functions as F

# Silver-layer pattern: join consent and apply filters before any sharing transformation
consent = spark.table("lh_silver.consumer_consent") \
    .filter(F.col("jurisdiction") == "CA-CCPA") \
    .filter(F.col("consent_status") == "active") \
    .select("subject_id", "opt_out_sale", "opt_out_share", "limit_spi_use", "gpc_signal_seen")

# Source data
events = spark.table("lh_silver.consumer_events_cleansed")

# Apply the joins — left so we keep records, but filter at write
gated = events.join(consent, on="subject_id", how="left") \
    .withColumn("effective_opt_out_sale",
                F.coalesce(F.col("opt_out_sale"), F.lit(False)) | F.coalesce(F.col("gpc_signal_seen"), F.lit(False))) \
    .withColumn("effective_opt_out_share",
                F.coalesce(F.col("opt_out_share"), F.lit(False)) | F.coalesce(F.col("gpc_signal_seen"), F.lit(False)))

# Write to a Gold view that downstream sharing pipelines consume
gated.filter(~F.col("effective_opt_out_sale")) \
     .filter(~F.col("effective_opt_out_share")) \
     .write.format("delta").mode("overwrite").saveAsTable("lh_gold.shareable_events")

💡 GPC bias toward consumer: When in doubt, treat GPC as opt-out. The CA AG has explicitly stated GPC is a valid opt-out signal.

Opt-Out Propagation Timing¶

CCPA mandates honoring opt-out within 15 business days of receipt.

Wire this as an SLO — if the pipeline misses 15 business days, you have an enforceable violation. See SLO/SLI doc for SLO patterns.

Cure Period (CPRA)¶

Until January 1, 2023, the CCPA had a 30-day cure period for any violation. CPRA sunset the automatic cure period but the CPPA may still grant a cure window at its discretion. For CCPA-only violations (still applicable to non-CPRA-amended provisions), the 45-day cure period applies if you receive a notice from the AG.

Practical implication: track cure_period_until per subject affected in a violation; document remediation steps; close out before expiration.

📨 DSAR Workflow¶

The Data Subject Access Request (DSAR) workflow under CCPA has specific verification and timing rules that differ from GDPR.

Verifiable Consumer Request¶

Three categories defined in the CCPA regulations:

Response Timing¶

Authorized Agents¶

Consumers may use an authorized agent (a person or business). Verification is layered:

• Verify the consumer (as above)
• Verify the agent has written authorization signed by the consumer
• For specific pieces of PI: notarized power of attorney recommended

Workflow in Fabric¶

sequenceDiagram
    participant C as Consumer
    participant W as Webform / Email
    participant DSAR as DSAR Service
    participant Ver as Verification
    participant F as Fabric (lh_silver)
    participant Aud as Audit Log

    C->>W: Submit request (right to know/delete/correct)
    W->>DSAR: Create DSAR ticket
    DSAR->>C: Acknowledge within 10 business days
    DSAR->>Ver: Initiate verification
    Ver->>C: Request verification data
    C->>Ver: Provide verification
    Ver->>DSAR: Verified
    DSAR->>F: Query consumer_consent + lakehouses
    F->>DSAR: Return data / confirm deletion
    DSAR->>C: Substantive response (≤45 days)
    DSAR->>Aud: Write immutable audit record

Audit record (per request) must capture:

• Request ID, type, received timestamp
• Consumer identifier (hashed if necessary)
• Verification method + outcome
• Response timestamp + content
• Exception cited (if refused)
• Operator who handled the request

See Audit Trail Immutability for tamper-evident DSAR records.

📋 Categories Disclosure Requirements¶

CCPA §1798.130 requires businesses to maintain — and update at least every 12 months — a publicly accessible disclosure listing.

Required Categories Table¶

For each of the prior 12 months, document:

Implementation as a Managed Table¶

CREATE TABLE IF NOT EXISTS lh_silver.pi_categories_disclosure (
    category                    STRING NOT NULL,
    description                 STRING NOT NULL,
    sources                     ARRAY<STRING>,
    business_purposes           ARRAY<STRING>,
    third_party_categories      ARRAY<STRING>,
    sold_or_shared              BOOLEAN,
    disclosed_for_biz_purpose   BOOLEAN,
    last_reviewed               TIMESTAMP NOT NULL,
    next_review_due             TIMESTAMP NOT NULL  -- <= now + 365 days
)
USING DELTA;

A scheduled pipeline (pipelines/categories_review_reminder.py) alerts the privacy team 30 days before next_review_due. This satisfies the annual update obligation.

🚦 GPC and Opt-Out Implementation¶

Global Privacy Control is a browser-level signal (an HTTP header Sec-GPC: 1 and DOM property Navigator.globalPrivacyControl) that the CA AG has confirmed is a legally binding opt-out signal.

Edge Detection Pattern¶

GPC must be detected at the edge — not deep in the application — so that no logging or pixel-firing happens before the opt-out is applied.

When the Subject Becomes Known¶

If a GPC-flagged anonymous session later identifies (login, conversion), carry the opt-out forward to the persistent subject_id record. Don't lose the signal at identification time.

# After login event, propagate session GPC opt-out to subject record
def merge_gpc_session_to_subject(session_id: str, subject_id: str) -> None:
    """Merge any GPC signal from anonymous session to identified subject."""
    spark.sql(f"""
    MERGE INTO lh_silver.consumer_consent target
    USING (
        SELECT '{subject_id}' AS subject_id, 'CA-CCPA' AS jurisdiction,
               TRUE AS gpc_signal_seen, current_timestamp() AS last_updated
        FROM lh_bronze.session_gpc_signals
        WHERE session_id = '{session_id}' AND gpc_seen = TRUE
    ) source
    ON target.subject_id = source.subject_id AND target.jurisdiction = source.jurisdiction
    WHEN MATCHED THEN UPDATE SET
        gpc_signal_seen = source.gpc_signal_seen,
        last_updated = source.last_updated
    WHEN NOT MATCHED THEN INSERT *
    """)

🛡️ SPI Limitation Implementation¶

When a consumer invokes the right to limit SPI use, OneLake Security row-level filters keep the data accessible for permitted uses but invisible to broader analytical workloads.

Step 1: Tag SPI in Purview¶

Apply Microsoft Purview sensitivity labels at the column level:

• Sensitive Personal Information - Government ID
• Sensitive Personal Information - Health
• Sensitive Personal Information - Geolocation Precise
• Sensitive Personal Information - Demographics

Step 2: Maintain SPI Column Registry¶

CREATE TABLE IF NOT EXISTS lh_silver.spi_columns (
    table_name      STRING NOT NULL,
    column_name     STRING NOT NULL,
    spi_category    STRING NOT NULL,    -- maps to CPRA SPI categories
    purview_label   STRING NOT NULL,
    last_validated  TIMESTAMP NOT NULL
)
USING DELTA;

Step 3: Apply OneLake Security Row Filter¶

-- OneLake Security row filter: hide SPI column values when limit_spi_use = TRUE
CREATE OR REPLACE FUNCTION lh_silver.fn_filter_spi_limited(subject_id STRING)
RETURNS BOOLEAN
RETURN NOT EXISTS (
    SELECT 1 FROM lh_silver.consumer_consent c
    WHERE c.subject_id = subject_id
      AND c.jurisdiction = 'CA-CCPA'
      AND c.limit_spi_use = TRUE
);

ALTER TABLE lh_silver.consumer_profile_enriched
SET ROW FILTER lh_silver.fn_filter_spi_limited(subject_id) ON (subject_id);

Step 4: Restrict Marketing/Analytics Pipelines¶

Pipelines flagged as "Marketing" or "Analytics" purposes use a read-only role that does not include the necessary-purpose-bypass for SPI. Pipelines for fraud detection or service fulfillment use a separate role that does bypass the filter, with logged justification.

See OneLake Security feature for label-based row filter patterns.

🤝 Service Provider vs Third Party¶

The single most common compliance failure is misclassifying a vendor.

The Distinction¶

Required Service Provider Contract Terms¶

A vendor only escapes "third party" status if the contract:

• Specifies the limited business purposes
• Prohibits selling or sharing the PI
• Prohibits retaining, using, or disclosing PI outside the direct business relationship
• Prohibits combining the PI with PI from other sources (with limited exceptions)
• Requires the vendor to comply with applicable CCPA obligations
• Grants the business audit rights

If even one clause is missing or weakened, the vendor is a third party and every disclosure to them is a "sale" requiring opt-out.

Implementation in Fabric¶

Maintain a vendor classification registry and a sub-processor list:

CREATE TABLE IF NOT EXISTS lh_silver.vendor_classification (
    vendor_id           STRING NOT NULL,
    vendor_name         STRING NOT NULL,
    classification      STRING NOT NULL,  -- 'service_provider', 'contractor', 'third_party'
    contract_id         STRING,
    contract_signed_at  DATE,
    contract_expires_at DATE,
    ccpa_clauses_verified BOOLEAN NOT NULL,
    sub_processor_list_published BOOLEAN NOT NULL,
    last_reviewed       TIMESTAMP NOT NULL
)
USING DELTA;

Any data export pipeline must check classification before delivering PI. If third_party and consumer has opt_out_sale = TRUE, block the export.

💰 Pricing & Non-Discrimination¶

CCPA §1798.125 prohibits discrimination against consumers for exercising rights — but allows differential treatment if "reasonably related to the value provided to the business by the consumer's data."

Permitted¶

• Loyalty programs with financial incentive notice (clear, opt-in)
• Tiered pricing based on data volume the consumer chooses to share, if disclosed
• Free service tiers with limited data collection, paid tiers with broader collection (must be optional)

Prohibited¶

• Denying goods/services to a consumer who exercised rights
• Charging different prices solely because the consumer opted out
• Providing different quality of service solely due to opt-out
• Threatening any of the above
• Coercing consent through "agree or no service" if alternatives are reasonably feasible

Casino Implementation Specifics¶

🎰 Casino practical: Players' Club tiers (Bronze/Silver/Gold/Platinum) determined by theoretical win, time on device, etc. — these are based on play behavior and are permissible. Marketing list opt-in is a separate flag and cannot affect tier benefits.

🎰 Casino Implementation¶

California Player Identification¶

Capture state-of-residence at enrollment. For each California player, the consent registry record is created automatically with default opt_out_sale = FALSE, opt_out_share = FALSE, limit_spi_use = FALSE.

Player Privacy Center¶

A dedicated portal section presents:

Consequences in Casino Pipelines¶

🏛️ Federal & Multi-State Implementation¶

CCPA was the first; it is no longer alone. As of 2026, comprehensive state privacy laws operate in:

Multi-State Consent Management¶

Maintain jurisdiction per consent record. Build a rules engine that resolves which regime applies for a given subject + activity:

def resolve_applicable_regimes(subject_state: str, activity: str) -> list[str]:
    """Return ordered list of regimes the activity must comply with."""
    regimes = []
    state_to_regime = {
        "CA": "CA-CCPA",
        "VA": "VA-VCDPA",
        "CO": "CO-CPA",
        "CT": "CT-CTDPA",
        # ...
    }
    if subject_state in state_to_regime:
        regimes.append(state_to_regime[subject_state])
    # Sectoral overlays
    if activity in ("hipaa_phi", "ferpa_education", "glba_finance"):
        regimes.append(activity)
    return regimes

Apply the strictest applicable rule for each operation. If California requires 15-day opt-out propagation but Colorado requires 45 days, propagate within 15.

Federal Posture¶

No comprehensive federal privacy law as of 2026. The American Privacy Rights Act (APRA) has been proposed but not enacted. Sectoral federal laws (HIPAA, GLBA, FERPA, COPPA) preempt for in-scope data. Plan multi-state CCPA-equivalent compliance as the pragmatic baseline.

🌍 Doing Both CCPA and GDPR¶

Most production Fabric workloads handle both California residents and EU/UK data subjects. The compliance strategy is layered, not parallel.

Operating Principle: Stricter Rule Wins¶

Dual Consent Records¶

The consumer_consent table from earlier supports both. The jurisdiction partition routes the rules; the lawful_basis column (add for GDPR) records the GDPR lawful basis:

ALTER TABLE lh_silver.consumer_consent ADD COLUMNS (
    lawful_basis        STRING,    -- GDPR: 'consent','contract','legal_obligation','vital','public','legitimate'
    consent_proof_uri   STRING,    -- GDPR: pointer to the consent record
    transfer_mechanism  STRING     -- GDPR: 'sccs','adequacy','derogation' for cross-border
);

Consent Management Platform¶

A consent management platform (Trust Arc, OneTrust, Osano, Cookiebot, or equivalent) provides:

• IAB TCF v2.2 strings for advertising
• GPC signal handling
• IAB GPP (Global Privacy Platform) signal — emerging multi-state standard
• Per-jurisdiction notice rendering
• Audit-ready opt-out logs

The CMP exports a JSON event stream → Bronze ingestion → consent registry. Treat the CMP as the system of record for opt-in/opt-out evidence, even if the canonical consent registry lives in Fabric.

🚫 Anti-Patterns¶

📋 Implementation Checklist¶

Before declaring CCPA/CPRA-ready:

• Scope determination: meet at least one of three thresholds (revenue, volume, mix)
• B2B and employee data treated as in-scope (post-2023 sunset)
• Privacy notice published with all CCPA-required disclosures
• "Do Not Sell or Share My Personal Information" link in homepage footer
• "Limit the Use of My Sensitive Personal Information" link if SPI is processed for non-essential purposes
• GPC signal detection at CDN/edge
• GPC signal honored as binding opt-out
• Consent management platform integrated
• lh_silver.consumer_consent registry deployed
• All Silver/Gold sharing pipelines gate on opt-out flags
• SPI columns labeled in Purview
• OneLake Security row filters apply for limit_spi_use = TRUE
• DSAR intake form (webform + email) live
• DSAR ticketing system in place
• Verification standards documented per request type
• Authorized agent verification process documented
• 10-business-day acknowledgment SLA tracked
• 45-day response SLA tracked with extension protocol
• First 2 requests/12 months are free
• Vendor classification registry maintained
• Every vendor contract verified for CCPA-required service-provider clauses
• Sub-processor list published and updated quarterly
• Categories disclosure table maintained with annual refresh reminder
• Loyalty / financial incentive program complies with §1798.125 notice rules
• No discrimination based on rights exercise (audit pricing, service quality)
• Opt-out propagation SLO ≤ 15 business days
• Multi-state regime resolver in place if applicable
• Joint CCPA + GDPR consent table schema if EU/UK subjects also handled
• DSAR audit log immutable and 24+ month retention
• Privacy team trained on cure period (45-day) response protocol
• Annual privacy program review on calendar

📚 References¶

CCPA / CPRA Statutes & Regulations¶

• California Consumer Privacy Act (CCPA) — CA Civil Code §1798.100 et seq.
• California Privacy Rights Act (CPRA) — Proposition 24 (2020)
• California Privacy Protection Agency (CPPA) Regulations
• California AG CCPA Resource
• Global Privacy Control (GPC) Specification
• IAB Global Privacy Platform (GPP)

Other State Statutes (Multi-State Reference)¶

• Virginia Consumer Data Protection Act (VCDPA)
• Colorado Privacy Act (CPA)
• Connecticut Data Privacy Act (CTDPA)
• Texas Data Privacy & Security Act (TDPSA)

Microsoft Resources¶

• Microsoft Compliance — CCPA
• Microsoft Purview Sensitivity Labels
• OneLake Security — Row & Column Filters
• Fabric Workspace Identity

Related Wave 5 Docs (this Wave)¶

• SOC 2 Type II Readiness (anchor)
• GDPR Right to Deletion (parallel doc)
• ISO 27001 Mapping
• STRIDE Threat Model
• Zero-Trust Blueprint
• Data Exfiltration Prevention
• Supply Chain Security
• Audit Trail Immutability

Related Existing Docs¶

• Data Governance Deep Dive
• Identity & RBAC Patterns
• OneLake Security Feature
• Customer-Managed Keys
• Network Security
• SLO/SLI for Fabric

Compliance Templates¶

• DSAR Runbook Template (Wave 5 batch 5b)
• CCPA Categories Disclosure Template (Wave 5 batch 5b)

⬆️ Back to Top | 📚 Security Index | 🏠 Home