ceo-orchestration 1.0.0

package/.claude/skills/core/compliance-lgpd/SKILL.md

@@ -0,0 +1,817 @@
+---
+name: compliance-lgpd
+description: LGPD (Lei 13.709/2018) compliance for a Brazilian SaaS platform.
+  Covers data subject rights, legal bases for processing, PII classification, data
+  retention, cookie consent, Terms of Service, Privacy Policy, cross-border data
+  transfer to AI providers, audit trails, breach notification, and DPO designation.
+  Use when discussing privacy, compliance, LGPD, terms of service, privacy policy,
+  data protection, PII, ANPD, data breach, cookie consent, cross-border transfer,
+  or any legal/regulatory requirement for {{PROJECT_NAME}}. Also use when reviewing
+  telemetry, logging, or AI integrations for PII exposure. If your product operates
+  in a regulated industry (finance, health, etc.), add domain-specific regulators
+  on top of the LGPD baseline described here.
+owner: Compliance Specialist (archetype)
+inspired_by:
+  - source: msitarzewski/agency-agents/specialized/compliance-auditor.md@783f6a72bfd7f3135700ac273c619d92821b419a
+    license: MIT
+    relationship: partial_reuse
+    authored_by: ceo-orchestration framework
+    authored_at: 2026-05-06
+# --- smart-loading fields (PLAN-083 Wave 0a sub-agent 0.7a) ---
+domain: core
+priority: 2
+risk_class: high
+stack: []
+context_budget_tokens: 1400
+inactive_but_retained: false
+repo_profile_binding:
+  frontend: {active: true, priority: 6}
+  engine: {active: true, priority: 4}
+  fintech: {active: true, priority: 2}
+  trading-readonly: {active: true, priority: 3}
+  generic: {active: true, priority: 7}
+activation_triggers:
+  - {event: help-me-invoked, regex: "(?i)lgpd|gdpr|privacy|pii"}
+---
+
+# LGPD Compliance for {{PROJECT_NAME}}
+
+## Fail-Fast Rule
+
+If any data processing operation lacks a valid legal basis, **stop and reject
+the operation**. Never collect, store, process, or transfer personal data without
+an explicit legal basis documented in the data processing registry. Never assume
+consent was given -- verify it.
+
+## Cardinal Rule
+
+**LGPD applies to ANY processing of personal data of individuals located in
+Brazil, regardless of where the data processor is located.** {{PROJECT_NAME}}
+operates as a Brazilian SaaS platform with users in Brazil. Every feature,
+endpoint, log, telemetry event, and third-party integration must be evaluated
+for LGPD compliance before shipping.
+
+## Audit Baseline: Typical Initial Gaps
+
+The following findings represent a typical starting compliance posture for a
+new SaaS product. Treat them as a checklist to validate against your own
+codebase:
+
+| Finding | Severity | Status |
+|---------|----------|--------|
+| Terms of Service not yet published | CRITICAL | Not started |
+| Privacy Policy not yet published | CRITICAL | Not started |
+| PII in telemetry logs (e.g. `client_telemetry` table storing `client_ip`, `user_id`, `session_id`) | HIGH | Identified |
+| User content sent to LLM providers without disclosure | HIGH | Identified |
+| No cookie consent mechanism | MEDIUM | Not started |
+| No data subject rights endpoints (access, deletion, portability) | HIGH | Not started |
+| No DPO designated | MEDIUM | Not started |
+| No data processing registry (ROPA) | HIGH | Not started |
+| Encrypted secrets at rest (e.g. AES-256-GCM for sensitive fields) but no key rotation policy | MEDIUM | Partial |
+| No data breach notification procedure | HIGH | Not started |
+
+## LGPD Legal Bases (Art. 7)
+
+For each category of data processing, {{PROJECT_NAME}} must identify one of
+these legal bases:
+
+| Legal Basis | LGPD Article | When to Use |
+|-------------|-------------|-------------|
+| Consent | Art. 7, I | Optional features: AI analysis, newsletter, behavioral analytics |
+| Contractual necessity | Art. 7, V | Core SaaS: account, billing, feature delivery |
+| Legitimate interest | Art. 7, IX | Security logs, fraud detection, product analytics (anonymized) |
+| Legal/regulatory obligation | Art. 7, II | Tax records, sector-specific regulatory reporting |
+| Credit protection | Art. 7, X | Billing dispute resolution |
+
+### {{PROJECT_NAME}} Data Processing Registry
+
+```
+| Data Category              | Legal Basis         | Retention    | Shared With          |
+|----------------------------|---------------------|--------------|----------------------|
+| User profile (email, name) | Contractual         | Account life + 5yr | Supabase, Stripe |
+| Sensitive credentials (enc)| Contractual         | Until revoked      | Never shared     |
+| User-generated content     | Contractual         | Account life       | Supabase         |
+| Usage data / activity      | Contractual         | Account life       | AI providers*    |
+| IP addresses (telemetry)   | Legitimate interest | 7 days             | Supabase         |
+| Session/browser data       | Legitimate interest | 7 days             | Supabase         |
+| AI analysis requests       | Consent             | 30 days            | Anthropic, OpenAI, Google |
+| Billing data               | Contractual         | 5 years (tax)      | Stripe           |
+| Public/aggregated data     | N/A                 | 90 days raw        | Public API       |
+| Derived analytics          | N/A (aggregated)    | 90 days            | None             |
+```
+
+*AI providers: Requires explicit consent + disclosure of which providers.
+
+## PII Classification for {{PROJECT_NAME}}
+
+### Directly Identifying PII
+
+- `profiles.email` -- account email
+- `profiles.full_name` -- display name
+- `client_telemetry.client_ip` -- IP address (PII under LGPD)
+- `client_telemetry.user_id` -- links to profile
+- Encrypted third-party credentials (`api_key_enc`) -- linked to user
+- Stripe `customer_id` -- links to payment identity
+
+### Indirectly Identifying PII
+
+- `client_telemetry.session_id` -- can correlate browsing patterns
+- `client_telemetry.browser`, `viewport`, `locale` -- device fingerprinting
+- `user_actions.*` -- behavior patterns that can be re-identified
+- User content (notes, messages, uploaded files) sent to AI -- may reveal identity
+
+### Non-Personal but Sensitive
+
+- Public reference data and aggregates -- not PII
+- System health metrics and logs (after PII scrubbing) -- not PII
+- Integration health metadata -- not PII
+
+## Data Subject Rights (LGPD Art. 18)
+
+{{PROJECT_NAME}} must implement endpoints for each right:
+
+### 1. Right of Access (Art. 18, II)
+
+```typescript
+// GET /api/privacy/my-data
+// Returns all personal data associated with the authenticated user.
+// Must include: profile, telemetry, activity history, user content,
+// AI analysis history, billing records, API keys (masked).
+// Response format: structured JSON + option for machine-readable export.
+// Deadline: 15 days from request (Art. 19).
+```
+
+### 2. Right of Correction (Art. 18, III)
+
+```typescript
+// PATCH /api/privacy/my-data
+// Allows correction of inaccurate personal data.
+// Fields: email, full_name, locale preferences.
+// Must propagate corrections to Stripe customer record.
+```
+
+### 3. Right of Deletion (Art. 18, VI)
+
+```typescript
+// DELETE /api/privacy/my-data
+// Deletes all personal data except what is legally required to retain.
+// Must delete: telemetry, session data, AI history, API keys.
+// Must retain: any records mandated by sector/tax law (e.g. invoices 5yr).
+// Must anonymize retained records (remove email, name linkage).
+// Must revoke all active sessions and API keys.
+// Must request deletion from Stripe (customer.delete).
+// Must NOT request deletion from AI providers (they have their own retention).
+// Document what was deleted vs retained and why.
+```
+
+### 4. Right of Portability (Art. 18, V)
+
+```typescript
+// GET /api/privacy/export
+// Returns all user data in a structured, machine-readable format (JSON).
+// Includes: profile, activity history, user content, API key metadata.
+// Must be delivered within 15 days (can be immediate for digital).
+// Format: JSON with clear schema documentation.
+```
+
+### 5. Right to Revoke Consent (Art. 18, IX)
+
+```typescript
+// POST /api/privacy/revoke-consent
+// Body: { scope: "ai_analysis" | "newsletter" | "telemetry" | "all" }
+// Immediately stops processing for the revoked scope.
+// AI analysis: stop sending user content to LLM providers.
+// Telemetry: stop collecting client_ip, browser, session data.
+// Must not degrade core service (contractual basis still valid).
+```
+
+### 6. Right to Information (Art. 18, I)
+
+```typescript
+// GET /api/privacy/processing-info
+// Public endpoint. Returns:
+// - What data is collected and why
+// - Legal basis for each category
+// - Third parties data is shared with
+// - Data retention periods
+// - How to exercise rights
+// - DPO contact information
+```
+
+## Cross-Border Data Transfer (LGPD Art. 33)
+
+### Example: Data Sent to AI Providers
+
+A typical SaaS may send user content and contextual data to one or more LLM
+providers for AI-powered features:
+
+| Provider | Location | Data Sent | Legal Mechanism |
+|----------|----------|-----------|-----------------|
+| Anthropic (Claude) | USA | User content + app context | Consent + Standard Contractual Clauses |
+| OpenAI (GPT) | USA | User content + app context | Consent + Standard Contractual Clauses |
+| Google (Gemini) | USA | User content + app context | Consent + Standard Contractual Clauses |
+
+### Requirements for Lawful Transfer
+
+1. **Explicit consent** (Art. 33, VIII): User must opt-in to AI analysis with
+   clear disclosure that data leaves Brazil.
+
+2. **Standard Contractual Clauses** (Art. 33, II-b): Verify each provider's
+   DPA (Data Processing Agreement) covers LGPD requirements.
+
+3. **Data minimization**: Send only the minimum data needed for analysis.
+   Strip email, name, IP from AI requests. Use anonymized representations
+   where possible.
+
+4. **Provider DPA review checklist**:
+   - Anthropic: Review usage policy for data retention (currently: no training on API data)
+   - OpenAI: Review DPA for LGPD compliance, data retention settings
+   - Google: Review Cloud DPA for Gemini API
+
+```typescript
+// CORRECT: Anonymized AI request
+const aiRequest = {
+  items: records.map(r => ({
+    type: r.type,           // generic classifier -- not PII
+    size_bucket: r.bucket,  // aggregate value -- not PII
+    created_at: r.created_at,
+  })),
+  app_context: { /* aggregated non-personal context */ },
+  // NO email, NO name, NO user_id, NO IP
+};
+
+// WRONG: Leaking PII to AI provider
+const aiRequest = {
+  user_email: user.email,  // NEVER
+  user_name: user.name,    // NEVER
+  ip: req.ip,              // NEVER
+  raw_records: records,    // may contain PII
+};
+```
+
+## Cookie Consent
+
+### Requirements
+
+{{PROJECT_NAME}} frontend (Vercel) must implement a cookie consent banner compliant
+with LGPD Art. 7, I (consent) and Art. 8 (consent requirements):
+
+1. **Before consent**: Only essential cookies (session, CSRF, auth).
+2. **After consent**: Analytics, telemetry, preferences.
+3. **Granular choices**: User must be able to accept/reject by category.
+4. **Easy withdrawal**: Consent must be as easy to revoke as to give.
+5. **Record of consent**: Store consent timestamp and scope in `profiles`.
+
+### Cookie Categories for {{PROJECT_NAME}}
+
+| Category | Examples | Legal Basis | Requires Consent |
+|----------|---------|-------------|-----------------|
+| Essential | Session JWT, CSRF token | Contractual | No |
+| Analytics | Page views, feature usage | Legitimate interest | Yes (opt-out) |
+| Telemetry | client_telemetry events | Legitimate interest | Yes (opt-out) |
+| Preferences | Locale, theme, dashboard layout | Consent | Yes |
+| Third-party | Stripe.js, AI provider calls | Consent | Yes |
+
+## Terms of Service Requirements
+
+### Mandatory Clauses for a Brazilian SaaS
+
+1. **Service description**: Concise description of what the product does and
+   for whom. Add any sector-specific capabilities your product offers.
+
+2. **User eligibility**: Age requirements (usually 18+) and any
+   jurisdiction-specific identifiers (e.g. CPF for Brazilian residents).
+
+3. **Account responsibilities**: Credential security, acceptable use.
+
+4. **Domain disclaimers**: Any disclaimers required by the sector your
+   product operates in. Common examples:
+   - Data is provided "as-is" with no guarantee of accuracy.
+   - AI outputs are informational only, not professional advice.
+   - Past performance does not guarantee future results.
+   - (If regulated: add the sector-specific disclaimers your regulator requires.)
+
+5. **Data processing**: Reference Privacy Policy. Explicit consent for AI features.
+
+6. **Subscription and billing**: Tier descriptions, pricing in the user's
+   currency, cancellation policy, refund policy (CDC Art. 49: 7-day regret
+   period for online purchases).
+
+7. **Intellectual property**: {{PROJECT_NAME}} owns the platform. Users own their data.
+
+8. **Limitation of liability**: Maximum liability = fees paid in last 12 months.
+   No liability for upstream service outages, data delays, or downstream losses.
+
+9. **Termination**: Either party can terminate. Data retention post-termination
+   per LGPD requirements.
+
+10. **Governing law**: Brazilian law (Lei 10.406/2002 Civil Code, CDC 8.078/1990).
+    Forum: Comarca of company registration.
+
+## Privacy Policy Requirements
+
+### Mandatory Sections (LGPD Art. 9)
+
+1. **Identity of controller**: Company name, CNPJ, address, DPO contact.
+
+2. **Data collected**: Full list by category (see PII Classification above).
+
+3. **Purpose of processing**: Specific purpose for each data category.
+
+4. **Legal basis**: Which Art. 7 basis applies to each processing activity.
+
+5. **Data sharing**: All third parties, their purposes, and safeguards.
+   Must list: Supabase (hosting), Stripe (billing), Anthropic/OpenAI/Google (AI),
+   your PaaS (e.g. Fly.io, Railway, Render, Heroku, AWS) (infrastructure).
+
+6. **International transfer**: Disclosure of data sent outside Brazil,
+   safeguards applied, user's right to object.
+
+7. **Retention periods**: Per-category retention (see registry above).
+
+8. **Data subject rights**: How to exercise each right, response deadlines.
+
+9. **Security measures**: Encryption at rest (Supabase), in transit (TLS),
+   credential encryption (AES-256-GCM), access controls.
+
+10. **Cookies**: Cookie policy (can be embedded or separate).
+
+11. **Updates**: How users are notified of policy changes.
+
+12. **DPO contact**: Name, email, phone.
+
+## Sector-Specific Regulations (Domain Overlay)
+
+LGPD is the baseline for any Brazilian product. Regulated industries add
+extra rules on top. Build a table for your own sector. Example shape:
+
+| Regulation | Scope | Impact on {{PROJECT_NAME}} |
+|-----------|-------|-------------------|
+| [Sector law] | [What it covers] | [What you must comply with] |
+| [Agency rule] | [Reporting obligations] | [Thresholds and frequency] |
+| [Tax authority guideline] | [Tax reporting] | [When you need to file and about whom] |
+| [AML/KYC requirements] | [If you move money or high-risk data] | [Identity verification, suspicious activity reports] |
+
+### {{PROJECT_NAME}} Classification
+
+Classify your product honestly against the sector rules. A typical SaaS
+might be a **data or workflow platform** with **limited direct regulatory
+exposure**, in which case LGPD alone may cover you. But if you handle
+money, health data, children's data, or other regulated categories, the
+sector overlay can be substantial.
+
+- **Pure SaaS (no regulated flows)**: LGPD only.
+- **Handles money/payments**: add financial regulator + AML/KYC rules.
+- **Handles health data**: add health regulator rules.
+- **Targets minors**: add ECA/COPPA-equivalent rules.
+
+Disclose to users which categories apply so they understand the full
+compliance posture.
+
+## Audit Trail Requirements
+
+### What Must Be Logged (Tamper-Evident)
+
+```typescript
+// audit_log table -- append-only, no UPDATE/DELETE policies
+interface AuditEntry {
+  id: bigint;
+  timestamp: string;         // ISO 8601
+  actor_type: 'user' | 'system' | 'admin' | 'webhook';
+  actor_id: string;          // user UUID or 'system'
+  action: string;            // 'login' | 'record_created' | 'consent_granted' | etc.
+  resource_type: string;     // 'profile' | 'record' | 'api_key' | 'consent'
+  resource_id: string;
+  details: Record<string, any>;  // action-specific context
+  ip_address: string;        // for accountability (retained per legal basis)
+  user_agent: string;
+}
+```
+
+### Required Audit Events
+
+- User login/logout (with IP)
+- Consent granted/revoked (with scope and timestamp)
+- Personal data access (who accessed, when, what)
+- Personal data export requested
+- Personal data deletion requested and executed
+- Business-critical mutations (per your domain)
+- API key created/revoked
+- Admin actions (tier changes, manual overrides)
+- Data breach detection
+
+### Retention for Audit Logs
+
+- Security events: 5 years (typical banking/regulated baseline)
+- Consent records: Duration of processing + 5 years
+- Business activity subject to tax/sector rules: per that rule (commonly 5 years)
+- General audit: 2 years minimum
+
+## Data Breach Notification (LGPD Art. 48)
+
+### Procedure
+
+1. **Detection**: Automated monitoring for unauthorized access, data exfiltration,
+   credential compromise. Check: Supabase audit logs, your PaaS access logs (e.g. Fly.io, Railway, Render, Heroku, AWS),
+   Stripe webhook anomalies.
+
+2. **Assessment** (within 24h):
+   - What data was compromised?
+   - How many data subjects affected?
+   - What is the risk level? (PII exposed? Financial data? Credentials?)
+
+3. **Notification to ANPD** (within 72h of awareness -- ANPD Resolucao CD/ANPD 15):
+   - Description of the incident
+   - Categories of data subjects affected
+   - Categories of personal data concerned
+   - Number of affected data subjects
+   - Measures taken to mitigate
+
+4. **Notification to data subjects** (if high risk):
+   - Clear, plain language description
+   - What data was affected
+   - What they should do (change passwords, revoke API keys)
+   - Contact for DPO
+
+5. **Remediation**:
+   - Revoke compromised credentials
+   - Rotate encryption keys if needed
+   - Patch vulnerability
+   - Update security measures
+   - Document lessons learned
+
+### Breach Notification Template
+
+```
+Subject: [{{PROJECT_NAME}}] Security Incident Notification
+
+We identified unauthorized access to [DESCRIPTION] on [DATE].
+
+Affected data: [LIST]
+Number of users affected: [COUNT]
+Actions taken: [MEASURES]
+
+What you should do:
+- Change your {{PROJECT_NAME}} password immediately
+- Revoke and regenerate any third-party credentials stored in {{PROJECT_NAME}}
+- Monitor connected accounts for unauthorized activity
+
+Contact our Data Protection Officer: [DPO_EMAIL]
+```
+
+## DPO Designation
+
+LGPD Art. 41 requires designation of a Data Protection Officer (Encarregado).
+
+Requirements:
+- Named individual or entity
+- Contact information publicly available (Privacy Policy + website)
+- Responsibilities: receive complaints, advise on data protection, interface
+  with ANPD, maintain processing records
+- Must be independent (no conflict of interest with business decisions)
+
+For early-stage: Can be the founder/CTO initially, but must be formally
+designated and published.
+
+## Implementation Priority
+
+| Priority | Item | Effort | Impact |
+|----------|------|--------|--------|
+| P0 | Privacy Policy (publish) | 2-3 days | Unblocks all compliance |
+| P0 | Terms of Service (publish) | 2-3 days | Legal protection |
+| P1 | Cookie consent banner | 1 day | Frontend + preferences table |
+| P1 | AI consent gate (opt-in before sending data to LLMs) | 1 day | Cross-border compliance |
+| P1 | client_telemetry IP anonymization (hash or truncate after 7d) | 0.5 day | PII reduction |
+| P2 | Data subject rights endpoints (access, delete, export) | 3-5 days | Art. 18 compliance |
+| P2 | Audit log table + event recording | 2-3 days | Accountability |
+| P2 | DPO designation + public contact | 0.5 day | Art. 41 |
+| P3 | Data processing registry (ROPA) document | 1-2 days | Art. 37 |
+| P3 | Breach notification procedure (documented) | 1 day | Art. 48 |
+| P3 | Provider DPA review (Anthropic, OpenAI, Google) | 2-3 days | Cross-border |
+
+## Telemetry PII Remediation
+
+### Current State: `client_telemetry` Table
+
+The `client_telemetry` table (sql/core_tables.sql) stores:
+- `client_ip` TEXT -- full IP address (PII under LGPD)
+- `user_id` TEXT -- direct user identifier
+- `session_id` TEXT -- correlatable to user
+- `browser` TEXT -- device fingerprinting component
+- `viewport` TEXT -- device fingerprinting component
+
+### Remediation Steps
+
+1. **IP anonymization**: Hash or truncate IP after 7 days.
+   ```sql
+   -- Daily cleanup: anonymize IPs older than 7 days
+   UPDATE public.client_telemetry
+   SET client_ip = 'anonymized'
+   WHERE created_at < NOW() - INTERVAL '7 days'
+   AND client_ip != 'anonymized';
+   ```
+
+2. **User ID pseudonymization**: For analytics, use hashed user_id.
+
+3. **Retention**: Delete telemetry rows older than 30 days (already 7d cleanup
+   exists in wiring.ts, but verify it runs).
+
+4. **Consent gate**: Only collect telemetry if user has consented to
+   "analytics" cookie category.
+
+## Anti-Patterns to Reject
+
+| Anti-Pattern | Why It's Wrong | Correct Approach |
+|---|---|---|
+| Collecting data "just in case" | Violates data minimization (Art. 6, III) | Collect only what's needed with documented purpose |
+| Burying consent in ToS | Consent must be separate and specific (Art. 8) | Granular consent per processing purpose |
+| Soft-delete for "deletion" requests | Data subject expects actual deletion | Hard delete + anonymize retained records |
+| Sending full user profile to AI | Data minimization violation | Strip PII, send only minimal task-specific payload |
+| IP logging without retention policy | Indefinite PII storage | Auto-anonymize after 7 days |
+| No audit trail for data access | Cannot prove compliance to ANPD | Append-only audit log for all PII operations |
+| Assuming consent once given is permanent | Consent can be revoked anytime (Art. 8, 5) | Check consent status before each processing |
+| Same legal basis for everything | Each processing needs its own basis | Map each data flow to specific Art. 7 basis |
+| Pre-checked consent boxes | Not freely given consent (Art. 8, 4) | Opt-in only, no defaults |
+| Treating public/aggregated data as PII | Over-compliance wastes resources | Classify correctly -- aggregated/non-personal data is not PII |
+
+## Compliance Frameworks Beyond LGPD
+
+LGPD is one node in a wider regulatory graph. A {{PROJECT_NAME}} deployment
+that crosses borders, accepts payment cards, handles patient data, or sells
+to enterprise buyers will face overlapping rule sets — each with its own
+articles, control catalog, evidence cadence, and auditor archetype. Treating
+them as independent verticals duplicates work. Treating them as one frame
+hides material differences. The table below is the discrimination matrix
+the Compliance Specialist consults before scoping any new audit cycle.
+
+| Framework | Scope trigger | Authority / certifier | Control catalog | Audit rhythm | Evidence shape |
+|---|---|---|---|---|---|
+| LGPD (this skill) | Personal data of subjects in Brazil | ANPD (regulator, not certifier) | LGPD Art. 6-9 + Resolucao CD/ANPD series | Continuous; spot inspections; mandatory breach notice 72h | DPIA, ROPA, consent ledger, breach log |
+| GDPR | Personal data of subjects in EU/EEA | National DPAs (e.g. CNIL [FR], BfDI [DE], AEPD [ES]) | GDPR Articles 5-32 + EDPB guidelines | Continuous; DPO maintains register; 72h breach notice | DPIA (Art. 35), Records of Processing (Art. 30), DPA chain |
+| UK GDPR | Personal data of subjects in the UK | ICO (Information Commissioner's Office) | UK GDPR + DPA 2018 | Continuous; complaint-driven enforcement; 72h breach notice | DPIA, ROPA, DPA chain; verify current ICO guidance on cross-border transfers (UK ↔ EEA), EU representative requirements, adequacy decisions, and Data (Use and Access) Act updates before treating UK and EU regimes as interchangeable |
+| SOC 2 (Type II) | US enterprise sales gating; trust criteria opt-in | AICPA-licensed CPA firm (third-party auditor) | TSC: CC1-CC9 + optional A1/C1/PI1/P1-P8 | Annual report covering 6-12 month observation window | Control narratives, sampled evidence per CC, exception log |
+| ISO/IEC 27001:2022 | International ISMS certification | Accredited certification body (e.g. BSI, DNV, Schellman) | Annex A: 93 controls across 4 themes (organizational, people, physical, tech) | Certification cycle: stage 1 + stage 2; surveillance year 1+2; recert year 3 | Statement of Applicability, risk register, internal audit reports, management review minutes |
+| HIPAA | Protected Health Information of US patients | HHS Office for Civil Rights (OCR) | 45 CFR Part 164 — Administrative, Physical, Technical safeguards | No certification; complaint-driven enforcement; HHS audit program | Risk analysis, BAAs with subprocessors, training logs, breach notifications |
+| PCI-DSS v4.0 | Storage/processing/transmission of cardholder data | QSA (third-party) for L1; SAQ for L2-L4 | 12 requirements grouped into 6 control objectives | Annual ROC or SAQ; quarterly ASV scans; ongoing | Network diagrams, scan reports, QSA workpapers, segmentation evidence |
+
+### Discrimination rules
+
+- **LGPD vs GDPR**: legal text is closely modeled but data-subject-rights
+  windows differ (LGPD Art. 19: 15 days; GDPR Art. 12: one month extendable).
+  Cross-border transfer mechanisms are NOT interchangeable — LGPD Art. 33
+  references its own list, not Standard Contractual Clauses templated by
+  the European Commission. NEVER assume a GDPR DPA satisfies LGPD by
+  default; the controller-processor language must mention LGPD or be
+  appended with an LGPD addendum citing Art. 33-39.
+- **SOC 2 vs ISO 27001**: SOC 2 produces an attestation report (text
+  consumed by buyers); ISO 27001 produces a certificate (binary pass/fail
+  consumed by procurement filters). A SOC 2 report can be shared under
+  NDA; a 27001 certificate is published. The two often share evidence
+  but the auditor's question shape differs — SOC 2 asks "did the control
+  operate over the period?", ISO asks "is the ISMS implemented and
+  maintained per the SoA?". DO NOT pitch one as "equivalent" to the
+  other to a buyer; they are not.
+- **HIPAA vs everything else**: HIPAA has no certifier — there is no
+  "HIPAA certified" badge. Vendors that claim it are either confused
+  or selling a third-party-attested control set. The framework's
+  position: when a counterparty asks "are you HIPAA compliant?", the
+  honest answer is "we sign a BAA and our controls map to the Security
+  Rule safeguards; here is the gap analysis", not "yes".
+- **PCI-DSS scope discipline**: scope creep is the #1 cost driver. If
+  cardholder data flows through {{PROJECT_NAME}} servers (even ephemerally),
+  every connected system is in scope. Use a tokenization provider
+  (Stripe.js, Adyen Drop-in, Braintree Hosted Fields) and verify the
+  PAN never reaches your TLS termination point. Network segmentation
+  evidence is what shrinks the audit surface — without it, the QSA
+  treats the entire VPC as in-scope.
+
+### Control overlap (one control, many frameworks)
+
+A single mature control answers multiple framework questions. Map once,
+satisfy many. Examples for a typical SaaS:
+
+| Control | LGPD | GDPR | SOC 2 | ISO 27001 | HIPAA | PCI-DSS |
+|---|---|---|---|---|---|---|
+| MFA on admin/production access | Art. 46 (security) | Art. 32 | CC6.1 | A.5.16, A.8.5 | 164.312(d) | Req 8.4 |
+| Encryption at rest for sensitive stores | Art. 46 | Art. 32 | CC6.1 / C1.1 | A.8.24 | 164.312(a)(2)(iv) | Req 3.5 |
+| Encryption in transit (TLS 1.2+) | Art. 46 | Art. 32 | CC6.7 | A.8.24 / A.8.20 | 164.312(e)(1) | Req 4.2 |
+| Quarterly access review | Art. 46 | Art. 32 | CC6.2 | A.5.18 | 164.308(a)(4) | Req 7.2 |
+| Vendor / subprocessor risk register | Art. 39 | Art. 28 | CC9.2 | A.5.19 | BAA inventory | Req 12.8 |
+| Centralized audit logging | Art. 37 | Art. 30 | CC7.2 | A.8.15, A.8.16 | 164.312(b) | Req 10 |
+| Documented incident response | Art. 48 | Art. 33-34 | CC7.4 | A.5.24-A.5.27 | 164.308(a)(6) | Req 12.10 |
+| Background checks on personnel with prod access | n/a (recommended) | Art. 32 | CC1.4 | A.6.1 | 164.308(a)(3) | Req 12.7 |
+
+The Compliance Specialist's job is to design the control once, write the
+evidence pipeline once, and produce the framework-specific narrative many
+times. NEVER author seven separate control documents for the same
+underlying mechanism.
+
+## Cross-Framework Evidence Pipeline
+
+Evidence collection breaks under manual labor at small scale and breaks
+spectacularly at scale. The framework's stance: every recurring evidence
+artifact gets a producer, a destination, a cadence, and a verification
+step. Manual collection is the exception, documented as such.
+
+### Evidence taxonomy (what every framework actually asks for)
+
+Six artifact families cover most asks. The framework names below are the
+canonical names — auditor terminology varies, but the underlying asks
+collapse to these six.
+
+| Family | Examples | Typical source | Cadence floor |
+|---|---|---|---|
+| Identity & access | IAM user list, group membership, MFA status, SSO config | IdP API (Okta, Entra ID, Google Workspace) + cloud IAM | Quarterly export with monthly delta |
+| Access reviews | Reviewer attestation per principal per system | GRC tool or ticketing workflow | Quarterly for prod; semiannual for non-prod |
+| Cryptographic posture | KMS key inventory, rotation state, TLS cert ages, cipher suites | KMS API + cert observability + nmap-tls | Continuous scan; monthly snapshot |
+| Vendor / subprocessor risk | DPA inventory, SOC 2 reports collected, sub-tier flow-down | Procurement system + GRC | Annual review per vendor; new-vendor before signing |
+| Incident & breach record | Postmortems, breach notifications, timeline | Ticketing + this skill's templates | Per event + monthly aggregate |
+| Change management | PR merge logs with approver, prod deploy log, schema migration log | Git host API + deploy pipeline + DB migration log | Continuous with monthly sample |
+
+### Pipeline architecture
+
+```
+producer (system of record)
+  -> exporter (scheduled job / webhook handler)
+  -> normalizer (convert to canonical schema)
+  -> evidence store (append-only, content-addressed, time-stamped)
+  -> indexer (control-id -> [artifact_uri, timestamp, hash] mapping)
+  -> auditor view (read-only export per control, per period)
+```
+
+Three properties the store MUST have:
+
+1. **Append-only with cryptographic timestamps.** A SOC 2 auditor's
+   #1 trick is asking for an artifact "as of date X". If the store
+   permits silent overwrites, the auditor cannot trust any artifact
+   they did not personally pull at the time. Use object-lock /
+   versioned-bucket / WORM storage; record the SHA256 + ingest
+   timestamp in a separate ledger.
+2. **Hash-chained ledger of ingestions.** Each evidence-store write
+   produces a ledger entry `(prev_hash, artifact_sha256, ts,
+   producer_id, control_id_set)`. The chain is independently
+   verifiable; tampering with one entry breaks the downstream chain.
+   This is the same pattern the framework's `audit_log` hook uses for
+   its own audit trail (HMAC-chained per-instance via `_lib/audit_emit.py`).
+3. **Read-only auditor view.** External auditors get a per-control,
+   per-period export — never raw store access. The view is generated
+   on demand and watermarked with the auditor's name and the request
+   timestamp; copies that leak get traced back.
+
+### CORRECT vs WRONG — evidence over time
+
+```
+# CORRECT — evidence captured continuously, sampled at audit time
+Q1 access review: ticket-1234 (closed 2025-04-12) reviewed 312 principals,
+  17 deprovisioned, evidence stored at evidence://access-reviews/2025-q1/...
+Q2 access review: ticket-1567 (closed 2025-07-08) reviewed 318 principals,
+  9 deprovisioned, evidence stored at evidence://access-reviews/2025-q2/...
+
+# WRONG — evidence rebuilt the week before the audit
+"We did access reviews quarterly. Here's a single spreadsheet covering
+all of 2025 that someone built last week from current Okta state."
+```
+
+The wrong pattern fails sampling. The auditor will pick a random month
+inside the period and ask "show me the deprovisioning of user X who
+left on 2025-04-30" — if the evidence is a year-end snapshot, the
+detail is gone and the control is rated `not effective` for the
+period. The fix is not to argue with the auditor; the fix is to build
+the pipeline in advance.
+
+### Multi-framework collection cadence
+
+A single artifact often satisfies multiple frameworks if collected at
+the highest-frequency framework's cadence. Example: a quarterly access
+review with documented reviewer attestation satisfies SOC 2 CC6.2 (any
+period in the audit window can be sampled), ISO 27001 A.5.18 (operating
+effectively), HIPAA 164.308(a)(4) (Information Access Management), and
+LGPD Art. 46 (security measures). One review, four narratives. NEVER
+run a separate "SOC 2 access review" and "ISO access review" — that is
+duplicated cost producing identical evidence.
+
+### Evidence-pipeline anti-patterns
+
+| Anti-Pattern | Failure mode | Correct approach |
+|---|---|---|
+| Manual screenshot evidence | Not reproducible; auditor cannot verify timestamp; attacker-tamperable | Programmatic export with embedded timestamp + content hash |
+| Single evidence run before audit | Sampling failure; period-of-effectiveness gap | Continuous capture; auditor samples the store, not a re-run |
+| Evidence stored in mutable bucket | Auditor cannot trust historical artifacts | Object-lock or WORM bucket with versioning |
+| One copy of each report | Loss of original auditor-watermarked copy | Per-auditor watermarked exports; originals retained in store |
+| Re-using last year's narrative verbatim | Spec drift between control as designed and control as operated | Annual re-walk of each control with current evidence; narrative is regenerated, not pasted |
+| Treating LGPD ROPA and GDPR Art. 30 register as separate documents | Duplicate maintenance; drift between them | Single processing registry with framework-mapping column |
+
+## Audit-Readiness Posture
+
+The Compliance Specialist runs an audit cycle in three phases. The phases
+are sequential — you do not start phase B before phase A produces a
+prioritized gap list, and phase C is driven by phase B's output, not by
+the auditor's first email.
+
+### Phase A — Readiness assessment
+
+Goal: produce an honest scorecard of the current control posture against
+the target framework's catalog. Deliverable is a per-control rating:
+`absent` / `documented-only` / `implemented` / `tested` / `audit-ready`.
+
+The auditor archetype rates conservatively. A control that exists in a
+runbook but has never been exercised is `documented-only`, not
+`implemented`. A control that runs but has no evidence trail is
+`implemented`, not `tested`. A control that is `audit-ready` has all
+of: written description, deployed mechanism, evidence in the pipeline,
+operating effectively for the entire intended audit period, and a named
+owner who can walk an external auditor through it.
+
+```
+# CORRECT — readiness scorecard with honest ratings
+CC6.1 Logical access controls
+  - Description: documented in policy v3.2 (2025-08-14)
+  - Mechanism: SSO + MFA enforced via IdP policy
+  - Evidence: weekly export of MFA-status from IdP API since 2025-09-01
+  - Period of operation: 6 weeks of evidence, audit window requires 6 months
+  - Rating: implemented (not yet audit-ready — need 5 more months of evidence)
+  - Owner: head-of-platform
+
+# WRONG — readiness scorecard built from optimism
+CC6.1 — "audit-ready" (because we have SSO and feel good about it)
+```
+
+The wrong pattern produces a false-confidence scorecard that crashes
+mid-audit. The right pattern produces an honest gap list that drives
+phase B.
+
+### Phase B — Gap remediation
+
+Goal: close the controls rated below `audit-ready`, in priority order
+weighted by `(audit-blocker severity) * (likelihood of being sampled) /
+(remediation effort)`. The Compliance Specialist publishes the gap list
+with owners and dates; the engineering org closes the gaps; the
+specialist re-rates each control as remediation lands.
+
+Two non-negotiables:
+
+1. **Period of operation matters.** A control rolled out two weeks
+   before the audit period closes generally cannot be claimed for the
+   full period. The remediation plan MUST account for this — either
+   move the audit window or scope the control to a future period.
+   NEVER claim period coverage that the evidence does not support.
+2. **Compensating controls are documented, not assumed.** When a
+   control gap cannot be closed in time, the substitute mechanism is
+   written down (what it is, why it covers the gap, who approved
+   it) and presented to the auditor proactively. Surprise compensating
+   controls discovered mid-audit produce findings.
+
+### Phase C — Auditor engagement
+
+Goal: produce a clean attestation/certificate. The cycle here is
+walkthrough → request-list → evidence delivery → finding → response →
+report. The framework's discipline applies at the conversation layer:
+
+- **Answer the question asked, not the question imagined.** The
+  auditor's request "show me how user provisioning works" is not an
+  invitation to walk through the entire IAM architecture. Pull the
+  control-specific evidence; offer the broader context only if asked.
+  NEVER volunteer information about controls outside the audit scope —
+  that material becomes a finding even if the in-scope control passes.
+- **A finding is not a fight.** When the auditor flags a gap, the
+  response sequence is: clarify the finding, agree on the underlying
+  fact, propose a remediation with date, document the compensating
+  control if any, accept or appeal in writing. Verbal pushback to a
+  finding without a written counter-proposal produces a worse rating,
+  not a better one.
+- **Scope discipline at the walkthrough.** The auditor's first
+  question — usually "tell me about your business" — is also a scoping
+  question. Volunteering "we also process some healthcare data for one
+  client" can pull HIPAA into a SOC 2 audit that did not require it.
+  Pre-rehearsed walkthrough scripts (one per control owner) prevent
+  this. The script answers the asked question and stops.
+- **Exceptions are written, not narrated.** Any deviation from the
+  control as designed (one server outside the standard, one user
+  exempt, one period without evidence) is documented with: who
+  approved, why, expiration date, compensating control. The auditor
+  will find the exception; the only question is whether you found it
+  first.
+
+### Audit-readiness posture anti-patterns
+
+| Anti-Pattern | Why it fails | Correct approach |
+|---|---|---|
+| "We're SOC 2 ready" with no scorecard | Self-rating without evidence collapses on contact with the auditor | Honest readiness scorecard per control before claiming readiness |
+| Building evidence the week before kickoff | Period-of-operation gap; sampling fails | Build evidence pipeline 6+ months before target audit window |
+| Letting engineering own the auditor relationship without a specialist | Engineers volunteer detail that auditors weaponize as scope | Compliance Specialist mediates; engineers answer specific questions through the specialist |
+| Treating findings as personal attacks | Defensive responses produce worse ratings | Findings are facts about the system; respond with remediation plans |
+| Skipping the walkthrough rehearsal | First-time-explained controls generate clarification rounds and findings | Rehearse each walkthrough; control owner can explain the control in two minutes |
+| Promising audit timeline without phase-A scorecard | Slip becomes inevitable; auditor confidence drops | Scorecard first; timeline derived from scorecard, not from leadership wishful thinking |
+| Bundling unrelated frameworks in one window | Cross-contamination of scope | Stagger frameworks; share evidence pipeline, not audit windows |
+
+## References
+
+- `core/security-and-auth` — auth + breach handling intersection (security
+  VETO floor under ADR-052)
+- `core/incident-management` — breach response procedure invoked from
+  Art. 48 path
+- `core/code-review-checklist` — the adversarial-framing methodology
+  used by the Compliance Specialist on phase-A readiness scorecards
+- `ADR-052` — multi-model dispatch by role (Compliance is a VETO-floor
+  archetype)
+- `domains/fintech/*` — sector overlay examples for regulated SaaS