Skill: BREACH_PLAYBOOK

Purpose

Maintain and exercise a detection-to-notification runbook so that any personal-data breach is contained, assessed, and notified within KVKK and GDPR statutory windows, with at least two tabletop drills per year.

Serves Goals

• Breach readiness: >=2 drills per year with gap list closed within 30 days.
• DSAR turnaround (indirect): post-breach DSAR volume spikes; playbook includes surge staffing.

Inputs

• Incident feed from incident-commander (triage outputs, containment status, scope).
• security-scanner outputs (recent vulnerabilities, active CVE watchlist).
• Processor list and their notification SLAs (iyzico, Supabase, etc.).
• Prior drill reports in outputs/.
• Regulatory reference: KVKK Art. 12 (notification "within the shortest time"; Board guidance: 72 hours to Board, "without delay" to affected persons); GDPR Art. 33 (72h to supervisory authority) and Art. 34 (to data subjects when high risk).

Process

A. Playbook Maintenance (non-incident mode)

1. Review KVKK Board decisions and EDPB breach guidance published since last revision; update runbook where controlling.
2. Review DPIA outputs for new residual-risk scenarios; add matching drill scripts.
3. Confirm processor notification contacts and SLAs still match contracts; flag mismatches to procurement via human.
4. Refresh notification templates (KVKK Board form, affected-persons notice in plain Turkish and English).
5. Version bump playbook; publish to outputs/.

B. Drill Execution (biannual)

1. Pick a scenario (for example: stolen admin session cookie exfiltrates client list; ransomware on backup; misconfigured Supabase RLS exposes PII; iyzico token leak).
2. Run tabletop with incident-commander, engineering on-call, and human leadership. Time each phase: detection, triage, containment, impact assessment, notification decision, notification drafting, affected-person outreach, post-mortem.
3. Score against the statutory clock: did the team have a Board-notification-ready packet within 72 hours of becoming aware?
4. Produce gap list; assign owners and 30-day deadlines.
5. Update playbook with lessons learned.

C. Real Incident Mode

1. On incident declaration by incident-commander with personal-data impact, this agent enters the response team.
2. Scope the breach: which data categories, how many data subjects, which jurisdictions, which processors involved.
3. Determine notification obligations:
   • KVKK Art. 12: notify the Board within the shortest time (Board guidance: 72h). Notify affected persons "without delay".
   • GDPR Art. 33: 72h to lead supervisory authority unless unlikely to result in risk. Art. 34: data subjects when high risk.
   • Processor contracts may trigger sub-notifications.
4. Draft the KVKK Board notification packet: nature of breach, categories and approximate number of data subjects, categories and approximate number of records, contact point, likely consequences, measures taken or proposed.
5. Draft the affected-persons notice: plain language, in Turkish (primary) and English; what happened, what data, what risks, what they can do, contact point.
6. Route all regulator-facing content through human + external legal counsel before send. This agent never sends.
7. Track the clock; log every milestone to journal.
8. Post-incident: run the full post-mortem with incident-commander, feed findings into MEMORY.md and into the next DPIA cycle.

Outputs

• outputs/YYYY-MM-DD_breach-playbook.md: current runbook version.
• outputs/YYYY-MM-DD_drill_<scenario-slug>.md: drill script, results, gap list.
• outputs/YYYY-MM-DD_incident_<incident-id>_kvkk-packet.md: real-incident notification packet (draft, for human sign-off).
• Journal entries for drills and real incidents.

Quality Bar

• Every playbook version has a named owner and a review date.
• Every drill produces a numeric score against the statutory clock.
• Every gap has an owner and a 30-day close target; misses escalate to human.
• Notification drafts are plain-language readable (target Turkish reading level: B1).
• No notification is ever sent externally by this agent; human sign-off mandatory.

Tools

• Incident channel feed from incident-commander.
• KVKK Board notification form (current version, referenced in templates).
• Context7 MCP for latest Board guidance and EDPB breach notification examples.

Integration

• incident-commander owns technical containment; this agent owns legal notification path.
• DPIA feeds scenario roster; high-residual-risk features get dedicated drills.
• CONSENT_AUDIT: breach scope determines which consent-holders must be notified even beyond strict legal threshold.
• DATA_SUBJECT_REQUEST: expect DSAR surge post-incident; playbook includes staffing plan.
• Hands all regulator-facing communication to human + external legal counsel for sign-off and send.

Skill: CONSENT_AUDIT

Purpose

Verify that every consent record held by GlossGo meets KVKK Art. 5 and GDPR Art. 6/7 requirements (freely given, specific, informed, unambiguous), with audit trail, version, and withdrawal path.

Serves Goals

• Consent coverage: 100% of active users with valid consent record.
• Policy freshness (indirect): surfaces cases where a policy version change invalidated prior consent.

Inputs

• Consent DB export from Supabase (data/imports/consent_export_YYYY-MM-DD.csv): user_id, purpose, lawful_basis, version_of_notice, timestamp, source_ip, ui_surface, withdrawal_at.
• Active user list from product DB export (to compute coverage ratio).
• Current Privacy Policy + KVKK Aydinlatma Metni version numbers from outputs/YYYY-MM-DD_privacy-policy-update.md.
• Outbound channel configs from email-lifecycle, whatsapp-commerce, social-media-manager (purposes they act on).
• RLS policy dump for tables with personal data.

Process

1. Load consent export; join against active user list to get coverage ratio.
2. For each record, validate the consent lawfulness matrix:
   • Specific: purpose string is one of the approved set (marketing-email, marketing-whatsapp, marketing-sms, social-tag, analytics, personalization, transactional is lawful basis "contract" not consent).
   • Informed: version_of_notice matches a currently or previously published policy version.
   • Freely given: not bundled with service acceptance (KVKK Art. 5, GDPR Art. 7(4)). Flag records where the consent was a precondition of signup.
   • Unambiguous: no pre-ticked boxes, no implied consent. UI surface must be in the approved list.
   • Withdrawable: a withdrawal path exists for that purpose in every touching system.
3. Cross-check each purpose against the acting agent's sender list:
   • marketing-email: does email-lifecycle's audience include any user without a valid consent row for this purpose?
   • marketing-whatsapp: same check against whatsapp-commerce.
   • social-tag: same check against social-media-manager.
4. Identify expired consent: version_of_notice older than 2 major policy revisions, or records older than the retention window defined in DATA_SUBJECT_REQUEST skill.
5. Check transactional vs marketing separation: purchase confirmations and appointment reminders ride on contract (KVKK Art. 5/2-c, GDPR Art. 6(1)(b)); they must not be gated on marketing consent.
6. Check minor-consent handling: if any user is under 18 and the region is Turkey, parental consent evidence must exist (KVKK Board guidance) or the account must be blocked from marketing purposes.
7. Produce a findings report with severity tier (P1 / P2 / P3), affected user counts, and remediation owner.
8. Open remediation items in MEMORY.md open-items table; notify affected agent via journal.

Outputs

• outputs/YYYY-MM-DD_consent-audit.md: coverage ratio, findings by severity, open items, remediation plan, next-audit date.
• Journal entry summarizing coverage delta and P1/P2 counts.
• Per-finding handoff ticket linked in the audit report.

Quality Bar

• Coverage ratio is computed from actual active-user list, not marketing-list proxy.
• Every finding cites the KVKK or GDPR article breached.
• Every P1 finding has a named owner agent and a target close date.
• Zero false-positives on transactional messages (they are not marketing; do not flag them as needing consent).
• Report reproducible: re-running on the same export yields identical findings.

Tools

• scripts/consent_coverage.sh: read-only SQL against Supabase consent table; outputs CSV.
• scripts/consent_lint.py (to be built): validates each row against the lawfulness matrix.
• Supabase MCP read-only role for RLS inspection.

Integration

• Hands remediation items to email-lifecycle, whatsapp-commerce, social-media-manager for consent repairs.
• Feeds DATA_SUBJECT_REQUEST skill: a pattern of withdrawal failures triggers a process fix.
• Feeds PRIVACY_POLICY_UPDATE: a recurring finding that the current notice is ambiguous on a purpose is a policy bug, not a per-user bug.
• Feeds DPIA: high-risk purposes recurring without consent cleanliness flag a systemic DPIA gap.

Skill: DATA_SUBJECT_REQUEST

Purpose

Run the end-to-end Data Subject Access Request workflow (access, rectification, erasure, restriction, portability, objection) with identity verification, SLA tracking, and a clean audit trail per KVKK Art. 11 and Art. 13 and GDPR Art. 15-22.

Serves Goals

• DSAR turnaround: <15 days (internal target; statutory maximum is KVKK Art. 13 30 days, GDPR Art. 12(3) one month).
• Consent coverage (indirect): withdrawal DSARs close the consent loop.

Inputs

• Inbound request (email, in-app form, letter). Channel-agnostic intake.
• Active user and identity records (read-only) for verification.
• Data inventory per user: which tables hold what, where soft-deletes live, which processors hold copies.
• Retention schedule table (see below).
• Prior DSARs in outputs/dsar/ for pattern reference.

Process

1. Intake and log: assign case ID DSAR-YYYY-NNNN. Create outputs/dsar/DSAR-YYYY-NNNN.md with request type, received date, channel, requester identity claim. Never put the requester's email in the filename.
2. Identity verification: confirm the requester controls the account. For KVKK, accept the verification methods listed in the Board's Communique on Application to the Data Controller. For suspicious or third-party requests, escalate to human; do not disclose anything until verified. If verification fails after two attempts over 15 days, close with a documented reason.
3. Classify the request:
   • Access (KVKK Art. 11(b)-(d) / GDPR Art. 15): compile data map + export.
   • Rectification (KVKK Art. 11(d) / GDPR Art. 16): validate correction, apply, notify processors.
   • Erasure / "right to be forgotten" (KVKK Art. 7 / GDPR Art. 17): check retention and legal-hold overrides (tax, contract performance, litigation). Hard-delete where applicable, anonymize where not.
   • Restriction (GDPR Art. 18): mark records restricted; no KVKK direct equivalent but aligned practice.
   • Portability (GDPR Art. 20): export in machine-readable format (JSON) for contract / consent-based processing only.
   • Objection (KVKK Art. 11(f) / GDPR Art. 21): stop marketing processing immediately; confirm lawful basis if processing continues under another basis.
4. Execute the action in read/write mode only through the human-approved runbook; this agent produces the packet, a human operator applies changes to production. Never auto-apply destructive changes.
5. Notify downstream processors and peer agents where required:
   • email-lifecycle, whatsapp-commerce, social-media-manager for marketing stop + suppression list add.
   • iyzico for tokenization/card data scope clarification (card data is not stored by glossgo; explain PCI-DSS scope in the response).
   • Supabase for any infrastructure-side actions (backups considered per retention schedule).
6. Draft response to requester: plain-language summary of action taken, data provided (as attachment for access / portability), legal references cited, right to complain to KVKK Board.
7. Route response through human for review where request type is erasure, rectification, or contains legally sensitive content; access/portability responses with standard data can go through lighter review.
8. Close case, update SLA clock, log to journal.

Retention Schedule (source of truth for erasure decisions)

Any erasure request must respect this table; the response explains retained categories and the legal basis.

Outputs

• outputs/dsar/DSAR-YYYY-NNNN.md: case file with timeline, actions, evidence, response draft.
• Data export file (JSON for portability, PDF for access) stored outside the repo in a controlled channel; case file contains hash and pointer only.
• Journal entry on case close: type, days to close, outcome.
• Monthly DSAR metrics summary into the weekly review.

Quality Bar

• Every case closes within 15 days or has a documented reason for extension (KVKK / GDPR both allow extensions for complex requests; extension notice sent within the original window).
• Identity verification evidence is captured; no disclosure without it.
• Erasure decisions cite the retention table and the overriding legal basis where data is retained.
• Responses are in Turkish by default; English on request.
• Audit trail is complete: who saw which record, when, why.

Tools

• Supabase MCP in read-only role for data-map compilation.
• DSAR case template in templates/ (to be added: templates/DSAR_CASE_TEMPLATE.md).
• Export tooling via a human-approved runbook (no direct production write from this agent).

Integration

• CONSENT_AUDIT: withdrawal DSARs feed the consent matrix.
• BREACH_PLAYBOOK: expect DSAR surge post-incident; surge staffing plan is cross-referenced.
• PRIVACY_POLICY_UPDATE: recurring DSAR themes (for example confusion about marketing opt-out) feed policy clarity fixes.
• email-lifecycle / whatsapp-commerce / social-media-manager: apply suppression list on objection and erasure cases; this agent verifies.
• Escalate to human + external legal counsel on: disputed identity, litigation-adjacent erasure, third-country requester invoking cross-border rights.

Skill: DPIA

Purpose

Run a Data Protection Impact Assessment for any feature classified high-risk before launch, per GDPR Art. 35 and KVKK Board guidance on high-risk processing.

Serves Goals

• DPIA coverage: >90% of high-risk features carry a signed DPIA at launch.
• Consent coverage (indirect): DPIAs surface missing lawful basis early.

Inputs

• Feature brief from product-roadmap (scope, data categories, processing purposes, data subjects, retention, third parties).
• Data-flow diagram or feature design doc.
• Current Privacy Policy + Aydinlatma Metni versions to check whether new processing is covered.
• security-scanner latest output for the affected codebase area (technical safeguards status).
• Prior DPIAs in outputs/ for pattern reuse.

Process

1. Threshold check: is a DPIA mandatory? Triggers include:
   • Systematic profiling with legal or similarly significant effects (GDPR Art. 35(3)(a)).
   • Large-scale processing of special categories (GDPR Art. 9 / KVKK Art. 6): health, biometrics, religion, ethnicity, sex life, criminal records.
   • Systematic monitoring of a publicly accessible area.
   • AI inference on personal data (KVKK Board indicative list, EDPB guidance).
   • Cross-border transfer to a non-adequate country (KVKK Art. 9).
   • New PII category collected (for example skin-tone analysis from photos, location trails).
   • Minors as the primary data subject group. If no trigger fires, produce a short no-DPIA rationale and stop.
2. Describe processing: nature, scope, context, purposes, data categories, data subjects, recipients, retention, international transfers.
3. Assess necessity and proportionality: is the data minimum needed? Could aggregate or on-device processing replace identified processing?
4. Identify lawful basis for each purpose (KVKK Art. 5/6; GDPR Art. 6/9). Pair consent purposes with the CONSENT_AUDIT matrix.
5. Risk analysis: for each risk identify likelihood, severity, affected rights (confidentiality, integrity, availability, Art. 11 data subject rights).
6. Mitigations: map each risk to controls (pseudonymization, encryption at rest and in transit, RLS policy, access log, retention policy, DPO review, contract with processor, Standard Contractual Clauses for transfer).
7. Residual risk: re-score after mitigations. If residual remains "high", escalate to human + external legal counsel; feature cannot launch until cleared.
8. Stakeholder consultation: note input from engineering, security-scanner, and (where required) data subjects or their representatives.
9. Draft DPIA document from template and circulate for sign-off: product-roadmap owner, engineering lead, this agent, human (as DPO proxy).
10. On approval, publish to outputs/, log to journal, update product-roadmap feature record with DPIA ID.

Outputs

• outputs/YYYY-MM-DD_dpia_<feature-slug>.md: structured DPIA per the process above.
• Journal entry with feature name, DPIA ID, residual risk tier, sign-off status.
• If residual high risk: escalation note with recommended Board consultation (KVKK Art. 38 prior consultation equivalent).

Quality Bar

• Every risk has likelihood and severity scored on the same ordinal scale across DPIAs.
• Every mitigation is linked to a concrete control (code change, config, contract clause), not an intent.
• Lawful basis cites the specific article subsection.
• Residual risk is conservatively stated; when in doubt, rate higher.
• DPIA is living: revisit annually or on material change.

Tools

• DPIA template in templates/ (to be added: templates/DPIA_TEMPLATE.md).
• security-scanner outputs for technical control evidence.
• Context7 MCP for current KVKK Board and EDPB guidance lookups.

Integration

• Triggered by product-roadmap when a new feature enters design review.
• Feeds CONSENT_AUDIT: new purposes identified in DPIA must appear in the consent matrix.
• Feeds PRIVACY_POLICY_UPDATE: any new processing purpose drives a policy revision.
• Feeds BREACH_PLAYBOOK: high-residual-risk features get bespoke breach scenarios added to the drill roster.
• Hands escalation to human for Board consultation where residual high risk cannot be reduced.

Skill: PRIVACY_POLICY_UPDATE

Purpose

Maintain the Privacy Policy, Terms of Service, KVKK Aydinlatma Metni, and cookie notice so they always reflect current processing, on a quarterly cadence plus event-driven updates.

Serves Goals

• Policy freshness: <90 days since last review.
• Consent coverage: policies define the purposes users consent to; drift here drives consent invalidation.
• DPIA coverage (indirect): policy gaps surface missing DPIAs.

Inputs

• Current published policy set (versioned).
• Change log since last review: DPIAs approved, new processors added, new features launched, new data categories, new regions.
• Peer agent activity summaries: email-lifecycle, whatsapp-commerce, social-media-manager (new campaigns, new channels), product-roadmap (launched features).
• Processor list / DPA register (iyzico, Supabase, any analytics, any AI provider).
• Regulatory signals: KVKK Board decisions and EDPB guidance published since last review.

Process

1. Inventory current processing: walk DPIA outputs + CONSENT_AUDIT matrix to produce the authoritative list of (purpose, lawful basis, data categories, retention, recipients, transfers).
2. Compare the inventory to the current policy text section by section:
   • Identity of the data controller (KVKK Art. 10 / GDPR Art. 13(1)(a)).
   • Purposes and lawful bases.
   • Data categories and sources.
   • Recipients and transfers (including iyzico for card tokenization, Supabase for hosting, any analytics or AI processors).
   • Retention periods.
   • Data subject rights (KVKK Art. 11 / GDPR Art. 15-22) and how to exercise them.
   • Cookies and trackers (ePrivacy-aligned cookie notice, even where ePrivacy does not apply, for audience consistency).
   • Contact for complaints (KVKK Board + internal contact).
3. For each mismatch, draft a redline. Classify risk: low (grammar / clarity), medium (new processor name, retention change), high (new lawful basis, new data category, new transfer).
4. Ship low-risk changes after internal review. Route medium-risk through human review. Route high-risk through human + external legal counsel.
5. Bump policy version and publish with a changelog entry accessible to users. Trigger a re-consent flow (via email-lifecycle / in-app) only when a change materially affects a purpose the user consented to.
6. Update Aydinlatma Metni specifically to cite KVKK articles and controller VERBIS registration number where required.
7. Update cookie notice with current tracker inventory, purposes, retention, and opt-out mechanics; cookie banner wording reviewed with product-roadmap.
8. Log the update, version bump, and any re-consent trigger to journal.

Outputs

• outputs/YYYY-MM-DD_privacy-policy-update.md: proposed redlines, risk classification, sign-off checklist, changelog entry, re-consent recommendation.
• Updated policy version numbers recorded in the audit ledger.
• Journal entry with version, change summary, whether re-consent was triggered.

Quality Bar

• Every statement in the policy is traceable to an inventory row (purpose, processor, retention).
• Aydinlatma Metni explicitly cites KVKK Art. 10 and references Art. 11 rights.
• No inconsistency between the English and Turkish policy versions; the Turkish Aydinlatma Metni is the legally controlling one in Turkey and takes precedence.
• Cookie notice distinguishes strictly necessary from optional trackers and honors do-not-track-equivalent opt-out.
• Change log is user-facing and dated.

Tools

• Versioned policy repository (external; this agent writes proposals, not the live policy).
• Context7 MCP for current KVKK Board and EDPB guidance.
• Diff tooling for redlines.

Integration

• Pulls inventory from DPIA outputs and CONSENT_AUDIT.
• Triggers re-consent flows executed by email-lifecycle (email) and in-app notice owned by product-roadmap.
• Any cross-border transfer added here triggers a BREACH_PLAYBOOK review of that processor's notification path.
• Hands high-risk redlines to human + external legal counsel; this agent never publishes policy text unilaterally.