compliance-check

Anthropic ｜ 商業與營運 ｜ 原文 ｜ Apache-2.0

檢查擬議行動的合規性，列出適用法規、核准與風險

---
name: compliance-check
description: 針對擬議的行動、產品功能或商業計畫做合規檢查，找出適用的法規、需要的核准和風險區域。用在上線會碰到個人資料的功能、行銷或產品提出有法規影響的做法，或是動工前需要知道適用哪些核准與管轄區要求的時候。
argument-hint: "<action or initiative to check>"
---

# /compliance-check -- 合規審查

> 如果看到不熟的佔位符，或需要確認目前連了哪些工具，請看 [CONNECTORS.md](../../CONNECTORS.md)。

針對擬議的行動、產品功能、行銷活動或商業計畫做合規檢查。

**重要**：這個指令是輔助法務工作流程，不提供法律意見。合規評估應該交給合格的法律專業人士審閱。法規變動很頻繁，一定要向權威來源確認最新的要求。

## 用法

```
/compliance-check $ARGUMENTS
```

## 我需要你提供什麼

描述你打算做的事。範例：
- 「我們想推出有現金回饋的推薦計畫」
- 「我們要在行動 app 加入生物辨識驗證」
- 「我們需要在美國的資料中心處理歐盟客戶的資料」
- 「行銷想在廣告裡使用客戶見證」

## 輸出

```markdown
## 合規檢查：[計畫]

### 摘要
[快速評估：可進行／附條件進行／需進一步審查]

### 適用的法規與政策
| 法規／政策 | 相關性 | 主要要求 |
|-------------------|-----------|-----------------|
| [GDPR / CCPA / HIPAA / 等] | [如何適用] | [你需要做什麼] |

### 要求
| # | 要求 | 狀態 | 需要的行動 |
|---|-------------|--------|---------------|
| 1 | [要求] | [已符合／未符合／未知] | [要做什麼] |

### 風險區域
| 風險 | 嚴重程度 | 緩解措施 |
|------|----------|------------|
| [風險] | [高／中／低] | [如何處理] |

### 建議行動
1. [最重要的行動]
2. [第二優先]
3. [第三優先]

### 需要的核准
| 核准者 | 原因 | 狀態 |
|----------|-----|--------|
| [人員／團隊] | [理由] | [待處理] |

### 建議進一步審查
[建議請外部律師或專家審閱的領域]
```

## 隱私法規概覽

### GDPR（General Data Protection Regulation，一般資料保護規則）

**適用範圍**：適用於處理歐盟／歐洲經濟區內個人的個人資料，不論處理資料的組織位於何處。

**對企業內部法務團隊的主要義務**：
- **合法基礎**：為每項處理活動找出並記錄合法基礎（同意、契約、正當利益、法律義務、重大利益、公共任務）
- **資料主體權利**：在 30 天內回應存取、更正、刪除、可攜、限制處理和反對的請求（複雜的請求可延長 60 天）
- **資料保護影響評估（DPIA）**：處理可能對個人造成高風險時必須做
- **外洩通報**：得知個資外洩後 72 小時內通知主管機關；如果風險高，要不延遲地通知受影響的個人
- **處理紀錄**：維護第 30 條規定的處理活動紀錄
- **國際傳輸**：確保傳輸到歐洲經濟區以外時有適當的保護措施（SCCs、適足性決定、BCRs）
- **DPO 要求**：需要時要指派資料保護長（公務機關、大規模處理特殊類別資料、大規模系統性監控）

**企業內部法務常見的接觸點**：
- 審查供應商的 DPA 是否符合 GDPR
- 就 privacy by design 的要求給產品團隊建議
- 回應主管機關的詢問
- 管理跨境資料傳輸機制
- 審查同意機制和隱私權聲明

### CCPA / CPRA（California Consumer Privacy Act / California Privacy Rights Act，加州消費者隱私法／加州隱私權法）

**適用範圍**：適用於蒐集加州居民個人資訊，且達到營收、資料量或資料販售門檻的企業。

**主要義務**：
- **知情權**：消費者可以要求揭露被蒐集、使用和分享的個人資訊
- **刪除權**：消費者可以要求刪除自己的個人資訊
- **退出權**：消費者可以選擇退出個人資訊的販售或分享
- **更正權**：消費者可以要求更正不正確的個人資訊（CPRA 新增）
- **限制使用敏感個人資訊的權利**：消費者可以把敏感個人資訊的使用限制在特定目的（CPRA 新增）
- **不歧視**：不能歧視行使權利的消費者
- **隱私權聲明**：必須在蒐集時或蒐集前提供隱私權聲明，說明蒐集的個人資訊類別和目的
- **服務提供者協議**：和服務提供者的契約必須把個人資訊的使用限制在指定的商業目的

**回應時限**：
- 10 個工作日內確認收到
- 45 個日曆天內實質回應（通知後可延長 45 天）

### 其他需要留意的重要法規

| 法規 | 管轄區 | 主要差異 |
|---|---|---|
| **LGPD**（巴西） | 巴西 | 和 GDPR 類似；要求指派 DPO；由國家資料保護局（ANPD）執法 |
| **POPIA**（南非） | 南非 | 由資訊監管機構監督；處理活動需登記 |
| **PIPEDA**（加拿大） | 加拿大（聯邦） | 以同意為基礎的框架；由 OPC 監督；正在現代化 |
| **PDPA**（新加坡） | 新加坡 | 拒絕來電登記；強制外洩通報；由 PDPC 執法 |
| **Privacy Act**（澳洲） | 澳洲 | 澳洲隱私原則（APPs）；應通報資料外洩制度 |
| **PIPL**（中國） | 中國 | 嚴格的跨境傳輸規則；資料在地化要求；由 CAC 監督 |
| **UK GDPR** | 英國 | 脫歐後的英國版本；由 ICO 監督；和歐盟 GDPR 類似，但有英國專屬的適足性 |

## DPA 審查清單

審查資料處理協議（Data Processing Agreement）或資料處理附約時，要確認以下項目：

### 必要要素（GDPR 第 28 條）

- [ ] **標的與期間**：清楚界定處理的範圍和期限
- [ ] **性質與目的**：具體描述會進行什麼處理、為什麼
- [ ] **個人資料類型**：被處理的個人資料類別
- [ ] **資料主體類別**：被處理的是誰的個人資料
- [ ] **控制者的義務與權利**：控制者的指示和監督權

### 處理者義務

- [ ] **只依書面指示處理**：處理者承諾只依控制者的指示處理（法律要求的情況例外）
- [ ] **保密**：獲授權處理的人員已承諾保密
- [ ] **安全措施**：說明適當的技術和組織措施（引用第 32 條）
- [ ] **次處理者要求**：
  - [ ] 書面授權的要求（一般授權或特定授權）
  - [ ] 如果是一般授權：異動要通知，並給予反對的機會
  - [ ] 次處理者透過書面協議受相同義務拘束
  - [ ] 處理者仍要對次處理者的履行負責
- [ ] **協助資料主體權利**：處理者會協助控制者回應資料主體的請求
- [ ] **安全與外洩協助**：處理者會協助履行安全義務、外洩通報、DPIA 和事前諮詢
- [ ] **刪除或返還**：終止時，刪除或返還所有個人資料（由控制者選擇），並刪除現有副本，除非法律要求保留
- [ ] **稽核權**：控制者有權進行稽核和檢查（或接受第三方稽核報告）
- [ ] **外洩通報**：處理者會不延遲地通知控制者個資外洩（理想是 24-48 小時內；必須讓控制者能趕上 72 小時的法定期限）

### 國際傳輸

- [ ] **已指明傳輸機制**：SCCs、適足性決定、BCRs 或其他有效機制
- [ ] **SCCs 版本**：如果適用，使用目前的歐盟 SCCs（2021 年 6 月版）
- [ ] **正確的模組**：選對適當的 SCC 模組（C2P、C2C、P2P、P2C）
- [ ] **傳輸影響評估**：如果傳輸到沒有適足性決定的國家，要完成評估
- [ ] **補充措施**：針對傳輸影響評估發現的缺口，採取技術、組織或契約上的措施
- [ ] **英國附約**：如果涉及英國個人資料，要附上英國國際資料傳輸附約

### 實務考量

- [ ] **責任**：DPA 的責任條款和主服務協議一致（或至少不衝突）
- [ ] **終止對齊**：DPA 的期限和服務協議一致
- [ ] **資料位置**：已指明處理地點，且可以接受
- [ ] **安全標準**：要求特定的安全標準或認證（SOC 2、ISO 27001 等）
- [ ] **保險**：資料處理活動有足夠的保險保障

### 常見的 DPA 問題

| 問題 | 風險 | 標準立場 |
|---|---|---|
| 概括授權次處理者，且不通知 | 失去對處理鏈的控制 | 要求通知，並保留反對權 |
| 外洩通報時限超過 72 小時 | 可能來不及向主管機關通報 | 要求 24-48 小時內通知 |
| 沒有稽核權（或只能透過第三方報告稽核） | 無法驗證合規 | 接受 SOC 2 Type II，加上有正當理由時可稽核的權利 |
| 沒有指定資料刪除時限 | 資料被無限期保留 | 要求終止後 30-90 天內刪除 |
| 沒有指定資料處理地點 | 資料可能在任何地方被處理 | 要求揭露處理地點 |
| 過期的 SCCs | 傳輸機制無效 | 要求使用目前的歐盟 SCCs（2021 年版） |

## 資料主體請求處理

### 請求受理

收到資料主體請求時：

1. **確認請求類型**：
   - 存取（取得個人資料副本）
   - 更正（修正不正確的資料）
   - 刪除（「被遺忘權」）
   - 限制處理
   - 資料可攜（結構化、機器可讀的格式）
   - 反對處理
   - 退出販售／分享（CCPA/CPRA）
   - 限制使用敏感個人資訊（CPRA）

2. **確認適用的法規**：
   - 資料主體位在哪裡？
   - 依你的組織據點和活動，適用哪些法律？
   - 具體的要求和時限是什麼？

3. **驗證身分**：
   - 確認請求人確實是本人
   - 採用和資料敏感度相稱的合理驗證措施
   - 不要要求過多的證明文件

4. **記錄請求**：
   - 收到日期
   - 請求類型
   - 請求人身分
   - 適用的法規
   - 回應期限
   - 指派的處理人

### 回應時限

| 法規 | 初步確認 | 實質回應 | 延長 |
|---|---|---|---|
| GDPR | 未規定（最佳實務：盡快） | 30 天 | +60 天（需通知） |
| CCPA/CPRA | 10 個工作日 | 45 個日曆天 | +45 天（需通知） |
| UK GDPR | 未規定（最佳實務：盡快） | 30 天 | +60 天（需通知） |
| LGPD | 未規定 | 15 天 | 有限度的延長 |

### 豁免與例外

履行請求之前，先檢查是否有任何豁免適用：

**各法規常見的豁免**：
- 為了抗辯或主張法律請求
- 法律義務要求保留
- 公共利益或公權力
- 言論與資訊自由（針對刪除請求）
- 為公共利益的存檔，或科學／歷史研究

**各組織特有的考量**：
- 訴訟保全（litigation hold）：處於法律保全狀態的資料不能刪除
- 法規保存期限：財務紀錄、僱傭紀錄和其他類別可能有強制保存期間
- 第三方權利：履行請求可能會損害他人的權利

### 回應流程

1. 蒐集請求人在各系統中的所有個人資料
2. 套用任何豁免，並記錄依據
3. 準備回應：履行請求，或說明為什麼（全部或部分）無法履行
4. 如果拒絕（全部或部分）：引用拒絕的具體法律依據
5. 告知請求人有權向主管機關提出申訴
6. 記錄回應，並保留請求與回應的紀錄

## 法規監控基礎

### 要監控什麼

持續留意以下方面的動態：
- **法規指引**：主管機關（ICO、CNIL、FTC、各州檢察總長等）發布的新指引或更新
- **執法行動**：顯示法規優先事項的罰款、命令與和解
- **立法變動**：新的隱私法、既有法律的修正、施行細則
- **產業標準**：ISO 27001、SOC 2、NIST 框架的更新，以及特定產業的要求
- **跨境傳輸的發展**：適足性決定、SCC 更新、資料在地化要求

### 監控做法

1. **訂閱主管機關的通訊**（電子報、RSS、官方公告）
2. **追蹤相關法律刊物**，看新發展的分析
3. **檢視產業協會的更新**，取得特定產業的指引
4. **維護一份法規行事曆**，記錄已知即將到來的期限、生效日和合規里程碑
5. **向法務團隊簡報**會影響組織處理活動的重大發展

### 升級條件

出現以下情況時，要把法規動態升級給資深律師或主管：
- 新法規或新指引直接影響組織的核心業務活動
- 組織所屬產業出現執法行動，顯示監管審查升高
- 有合規期限逼近，需要組織做出改變
- 組織所依賴的資料傳輸機制被挑戰或宣告無效
- 主管機關對組織展開詢問或調查

## 小提醒

1. **要具體**：「我們想寄信給所有使用者」比「行銷活動」好。
2. **要包含地區**：合規要求因管轄區而異。
3. **要提到資料**：涉及哪些個人資料？大部分合規要求都由這個決定。

---
name: compliance-check
description: Run a compliance check on a proposed action, product feature, or business initiative, surfacing applicable regulations, required approvals, and risk areas. Use when launching a feature that touches personal data, when marketing or product proposes something with regulatory implications, or when you need to know which approvals and jurisdictional requirements apply before proceeding.
argument-hint: "<action or initiative to check>"
---

# /compliance-check -- Compliance Review

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Run a compliance check on a proposed action, product feature, marketing campaign, or business initiative.

**Important**: This command assists with legal workflows but does not provide legal advice. Compliance assessments should be reviewed by qualified legal professionals. Regulatory requirements change frequently; always verify current requirements with authoritative sources.

## Usage

```
/compliance-check $ARGUMENTS
```

## What I Need From You

Describe what you're planning to do. Examples:
- "We want to launch a referral program with cash rewards"
- "We're adding biometric authentication to our mobile app"
- "We need to process EU customer data in our US data center"
- "Marketing wants to use customer testimonials in ads"

## Output

```markdown
## Compliance Check: [Initiative]

### Summary
[Quick assessment: Proceed / Proceed with conditions / Requires further review]

### Applicable Regulations and Policies
| Regulation/Policy | Relevance | Key Requirements |
|-------------------|-----------|-----------------|
| [GDPR / CCPA / HIPAA / etc.] | [How it applies] | [What you need to do] |

### Requirements
| # | Requirement | Status | Action Needed |
|---|-------------|--------|---------------|
| 1 | [Requirement] | [Met / Not Met / Unknown] | [What to do] |

### Risk Areas
| Risk | Severity | Mitigation |
|------|----------|------------|
| [Risk] | [High/Med/Low] | [How to address] |

### Recommended Actions
1. [Most important action]
2. [Second priority]
3. [Third priority]

### Approvals Needed
| Approver | Why | Status |
|----------|-----|--------|
| [Person/Team] | [Reason] | [Pending] |

### Further Review Recommended
[Areas where outside counsel or specialist review is advised]
```

## Privacy Regulation Overview

### GDPR (General Data Protection Regulation)

**Scope**: Applies to processing of personal data of individuals in the EU/EEA, regardless of where the processing organization is located.

**Key Obligations for In-House Legal Teams**:
- **Lawful basis**: Identify and document lawful basis for each processing activity (consent, contract, legitimate interest, legal obligation, vital interest, public task)
- **Data subject rights**: Respond to access, rectification, erasure, portability, restriction, and objection requests within 30 days (extendable by 60 days for complex requests)
- **Data protection impact assessments (DPIAs)**: Required for processing likely to result in high risk to individuals
- **Breach notification**: Notify supervisory authority within 72 hours of becoming aware of a personal data breach; notify affected individuals without undue delay if high risk
- **Records of processing**: Maintain Article 30 records of processing activities
- **International transfers**: Ensure appropriate safeguards for transfers outside EEA (SCCs, adequacy decisions, BCRs)
- **DPO requirement**: Appoint a Data Protection Officer if required (public authority, large-scale processing of special categories, large-scale systematic monitoring)

**Common In-House Legal Touchpoints**:
- Reviewing vendor DPAs for GDPR compliance
- Advising product teams on privacy by design requirements
- Responding to supervisory authority inquiries
- Managing cross-border data transfer mechanisms
- Reviewing consent mechanisms and privacy notices

### CCPA / CPRA (California Consumer Privacy Act / California Privacy Rights Act)

**Scope**: Applies to businesses that collect personal information of California residents and meet revenue, data volume, or data sale thresholds.

**Key Obligations**:
- **Right to know**: Consumers can request disclosure of personal information collected, used, and shared
- **Right to delete**: Consumers can request deletion of their personal information
- **Right to opt-out**: Consumers can opt out of the sale or sharing of personal information
- **Right to correct**: Consumers can request correction of inaccurate personal information (CPRA addition)
- **Right to limit use of sensitive personal information**: Consumers can limit use of sensitive PI to specific purposes (CPRA addition)
- **Non-discrimination**: Cannot discriminate against consumers who exercise their rights
- **Privacy notice**: Must provide a privacy notice at or before collection describing categories of PI collected and purposes
- **Service provider agreements**: Contracts with service providers must restrict use of PI to the specified business purpose

**Response Timelines**:
- Acknowledge receipt within 10 business days
- Respond substantively within 45 calendar days (extendable by 45 days with notice)

### Other Key Regulations to Monitor

| Regulation | Jurisdiction | Key Differentiators |
|---|---|---|
| **LGPD** (Brazil) | Brazil | Similar to GDPR; requires DPO appointment; National Data Protection Authority (ANPD) enforcement |
| **POPIA** (South Africa) | South Africa | Information Regulator oversight; required registration of processing |
| **PIPEDA** (Canada) | Canada (federal) | Consent-based framework; OPC oversight; being modernized |
| **PDPA** (Singapore) | Singapore | Do Not Call registry; mandatory breach notification; PDPC enforcement |
| **Privacy Act** (Australia) | Australia | Australian Privacy Principles (APPs); notifiable data breaches scheme |
| **PIPL** (China) | China | Strict cross-border transfer rules; data localization requirements; CAC oversight |
| **UK GDPR** | United Kingdom | Post-Brexit UK version; ICO oversight; similar to EU GDPR with UK-specific adequacy |

## DPA Review Checklist

When reviewing a Data Processing Agreement or Data Processing Addendum, verify the following:

### Required Elements (GDPR Article 28)

- [ ] **Subject matter and duration**: Clearly defined scope and term of processing
- [ ] **Nature and purpose**: Specific description of what processing will occur and why
- [ ] **Type of personal data**: Categories of personal data being processed
- [ ] **Categories of data subjects**: Whose personal data is being processed
- [ ] **Controller obligations and rights**: Controller's instructions and oversight rights

### Processor Obligations

- [ ] **Process only on documented instructions**: Processor commits to process only per controller's instructions (with exception for legal requirements)
- [ ] **Confidentiality**: Personnel authorized to process have committed to confidentiality
- [ ] **Security measures**: Appropriate technical and organizational measures described (Article 32 reference)
- [ ] **Sub-processor requirements**:
  - [ ] Written authorization requirement (general or specific)
  - [ ] If general authorization: notification of changes with opportunity to object
  - [ ] Sub-processors bound by same obligations via written agreement
  - [ ] Processor remains liable for sub-processor performance
- [ ] **Data subject rights assistance**: Processor will assist controller in responding to data subject requests
- [ ] **Security and breach assistance**: Processor will assist with security obligations, breach notification, DPIAs, and prior consultation
- [ ] **Deletion or return**: On termination, delete or return all personal data (at controller's choice) and delete existing copies unless legal retention required
- [ ] **Audit rights**: Controller has right to conduct audits and inspections (or accept third-party audit reports)
- [ ] **Breach notification**: Processor will notify controller of personal data breaches without undue delay (ideally within 24-48 hours; must enable controller to meet 72-hour regulatory deadline)

### International Transfers

- [ ] **Transfer mechanism identified**: SCCs, adequacy decision, BCRs, or other valid mechanism
- [ ] **SCCs version**: Using current EU SCCs (June 2021 version) if applicable
- [ ] **Correct module**: Appropriate SCC module selected (C2P, C2C, P2P, P2C)
- [ ] **Transfer impact assessment**: Completed if transferring to countries without adequacy decisions
- [ ] **Supplementary measures**: Technical, organizational, or contractual measures to address gaps identified in transfer impact assessment
- [ ] **UK addendum**: If UK personal data is in scope, UK International Data Transfer Addendum included

### Practical Considerations

- [ ] **Liability**: DPA liability provisions align with (or don't conflict with) the main services agreement
- [ ] **Termination alignment**: DPA term aligns with the services agreement
- [ ] **Data locations**: Processing locations specified and acceptable
- [ ] **Security standards**: Specific security standards or certifications required (SOC 2, ISO 27001, etc.)
- [ ] **Insurance**: Adequate insurance coverage for data processing activities

### Common DPA Issues

| Issue | Risk | Standard Position |
|---|---|---|
| Blanket sub-processor authorization without notification | Loss of control over processing chain | Require notification with right to object |
| Breach notification timeline > 72 hours | May prevent timely regulatory notification | Require notification within 24-48 hours |
| No audit rights (or audit rights only via third-party reports) | Cannot verify compliance | Accept SOC 2 Type II + right to audit upon cause |
| Data deletion timeline not specified | Data retained indefinitely | Require deletion within 30-90 days of termination |
| No data processing locations specified | Data could be processed anywhere | Require disclosure of processing locations |
| Outdated SCCs | Invalid transfer mechanism | Require current EU SCCs (2021 version) |

## Data Subject Request Handling

### Request Intake

When a data subject request is received:

1. **Identify the request type**:
   - Access (copy of personal data)
   - Rectification (correction of inaccurate data)
   - Erasure / deletion ("right to be forgotten")
   - Restriction of processing
   - Data portability (structured, machine-readable format)
   - Objection to processing
   - Opt-out of sale/sharing (CCPA/CPRA)
   - Limit use of sensitive personal information (CPRA)

2. **Identify applicable regulation(s)**:
   - Where is the data subject located?
   - Which laws apply based on your organization's presence and activities?
   - What are the specific requirements and timelines?

3. **Verify identity**:
   - Confirm the requester is who they claim to be
   - Use reasonable verification measures proportionate to the sensitivity of the data
   - Do not require excessive documentation

4. **Log the request**:
   - Date received
   - Request type
   - Requester identity
   - Applicable regulation
   - Response deadline
   - Assigned handler

### Response Timelines

| Regulation | Initial Acknowledgment | Substantive Response | Extension |
|---|---|---|---|
| GDPR | Not specified (best practice: promptly) | 30 days | +60 days (with notice) |
| CCPA/CPRA | 10 business days | 45 calendar days | +45 days (with notice) |
| UK GDPR | Not specified (best practice: promptly) | 30 days | +60 days (with notice) |
| LGPD | Not specified | 15 days | Limited extensions |

### Exemptions and Exceptions

Before fulfilling a request, check whether any exemptions apply:

**Common exemptions across regulations**:
- Legal claims defense or establishment
- Legal obligations requiring retention
- Public interest or official authority
- Freedom of expression and information (for erasure requests)
- Archiving in the public interest or scientific/historical research

**Organization-specific considerations**:
- Litigation hold: Data subject to a legal hold cannot be deleted
- Regulatory retention: Financial records, employment records, and other categories may have mandatory retention periods
- Third-party rights: Fulfilling the request might adversely affect the rights of others

### Response Process

1. Gather all personal data of the requester across systems
2. Apply any exemptions and document the basis
3. Prepare response: fulfill the request or explain why (in whole or part) it cannot be fulfilled
4. If denying (in whole or part): cite the specific legal basis for denial
5. Inform the requester of their right to lodge a complaint with the supervisory authority
6. Document the response and retain records of the request and response

## Regulatory Monitoring Basics

### What to Monitor

Maintain awareness of developments in:
- **Regulatory guidance**: New or updated guidance from supervisory authorities (ICO, CNIL, FTC, state AGs, etc.)
- **Enforcement actions**: Fines, orders, and settlements that signal regulatory priorities
- **Legislative changes**: New privacy laws, amendments to existing laws, implementing regulations
- **Industry standards**: Updates to ISO 27001, SOC 2, NIST frameworks, and sector-specific requirements
- **Cross-border transfer developments**: Adequacy decisions, SCC updates, data localization requirements

### Monitoring Approach

1. **Subscribe to regulatory authority communications** (newsletters, RSS feeds, official announcements)
2. **Track relevant legal publications** for analysis of new developments
3. **Review industry association updates** for sector-specific guidance
4. **Maintain a regulatory calendar** of known upcoming deadlines, effective dates, and compliance milestones
5. **Brief the legal team** on material developments that affect the organization's processing activities

### Escalation Criteria

Escalate regulatory developments to senior counsel or leadership when:
- A new regulation or guidance directly affects the organization's core business activities
- An enforcement action in the organization's sector signals heightened regulatory scrutiny
- A compliance deadline is approaching that requires organizational changes
- A data transfer mechanism the organization relies on is challenged or invalidated
- A regulatory authority initiates an inquiry or investigation involving the organization

## Tips

1. **Be specific** — "We want to email all our users" is better than "marketing campaign."
2. **Include the geography** — Compliance requirements vary by jurisdiction.
3. **Mention the data** — What personal data is involved? This drives most compliance requirements.