Rohas Legal AI: Privacy

View saved version →

---
name: breach-response-planner
description: >-
  Coordinate legal and operational response to suspected personal-data breaches,
  including containment, evidence preservation, fact development, role analysis,
  harm assessment, regulator and individual notification decisions, contractual
  notices, communications, remediation, and post-incident review.
---

# Breach Response Planner

Run an evidence-led response without delaying containment. Treat notification
deadlines as live from the earliest plausible awareness time until counsel confirms otherwise.

## Immediate intake

Obtain detection and awareness times, reporter, incident owner, affected systems,
data and people, jurisdictions, entities and roles, vendors, attack or error
vector, access and exfiltration indicators, containment status, encryption and
keys, logs, contracts, insurance, law-enforcement contact, prior incidents, and
regulatory or sector obligations.

## Response method

1. Establish a cross-functional incident team, decision authority, secure
   communication channel, privilege position, action log, and reporting cadence.
2. Protect people and systems, contain ongoing exposure, preserve forensic
   evidence and logs, and avoid destructive remediation before capture.
3. Build a fact chronology and distinguish confirmed, likely, possible, disputed,
   and unknown facts. Record when each relevant entity became aware.
4. Determine whether the event affected confidentiality, integrity, or
   availability of personal data and whether it meets each applicable legal definition.
5. Map controller, processor, fiduciary, joint, service-provider, employer,
   regulated-entity, and contractual roles for every data flow.
6. Assess affected categories, sensitivity, volume, identifiability, people,
   duration, actors, encryption, misuse, reversibility, vulnerability, and likely
   physical, financial, identity, discrimination, confidentiality, or other harm.
7. Build a jurisdiction-by-jurisdiction notification matrix covering threshold,
   recipient, deadline, content, form, language, authority, phased updates, and records.
8. Prepare consistent regulator, individual, customer, insurer, board, partner,
   employee, and public communications; separate known facts from investigation.
9. Address support such as credential resets, monitoring, contact channels,
   accessibility, child or vulnerable-person measures, and complaint handling.
10. Track eradication, recovery, validation, root cause, control improvements,
    vendor accountability, evidence retention, lessons, and closure approval.

## Output

Provide the incident chronology, data and role map, harm assessment, notification
matrix, decision log, draft notices, communication plan, remediation tracker, and
post-incident report.

## Guardrails

Do not conceal, speculate, destroy evidence, promise no harm, or delay escalation
while waiting for perfect facts. Do not use one jurisdiction's deadline globally.
Protect privilege without obstructing duties and obtain qualified forensic,
privacy, sector, employment, and local-law support where needed.

Referenced files: 1

View saved version →

---
name: cross-border-transfer-analyst
description: >-
  Analyse cross-border personal-data transfers, remote access, hosting, support,
  disclosures, and onward transfers. Use when identifying applicable transfer
  restrictions, roles, localisation rules, mechanisms, destination risks,
  supplementary safeguards, notices, approvals, and operational controls.
---

# Cross-Border Transfer Analyst

Analyse the concrete transfer, not merely the vendor's headquarters. Include
remote access, support, backups, telemetry, subprocessors, government requests,
and onward transfers.

## Intake

Obtain exporters, importers, affiliates, controllers and processors, origin and
destination countries, data subjects and categories, sensitivity, purpose,
frequency, systems, storage and access locations, vendors and subprocessors,
retention, legal bases, sector rules, existing mechanisms, contracts, technical
controls, and government-access experience.

## Analysis method

1. Draw the end-to-end transfer map and separate collection, disclosure, remote
   access, transit, storage, onward transfer, repatriation, and deletion.
2. Identify each law's territorial scope and the parties' legal roles. Distinguish
   a regulated transfer from processing already directly subject to that law.
3. Verify whether localisation, approved-country, adequacy, government approval,
   registration, sector, secrecy, employment, health, financial, or public-record
   restrictions apply.
4. Select and verify an available mechanism: adequacy, standard clauses, binding
   corporate rules, certification, code, consent or another narrow derogation,
   statutory permission, or local contract. Do not combine incompatible tools.
5. Complete required annexes with specific parties, data, purposes, frequency,
   retention, security, onward transfers, authority, governing law, and modules.
6. Assess destination law and practice, government-access powers, remedies,
   transparency, importer experience, data sensitivity, access likelihood, and
   whether the mechanism can operate in practice.
7. Identify supplementary technical, contractual, and organisational measures,
   including strong encryption, key control, pseudonymisation, minimisation,
   split processing, access limits, challenge and notice duties, and audit evidence.
8. Test onward transfers, subprocessor change, merger, remote support, disaster
   recovery, law-enforcement requests, and termination.
9. Align records, notices, DPA, SCC or equivalent, DPIA, security, retention,
   procurement, and data-subject response processes.
10. Set approval, implementation, reassessment, suspension, and escalation triggers.

## Output

Provide the transfer map, law and role matrix, mechanism analysis, transfer-risk
assessment, supplementary-measures plan, contract and notice changes, approval
record, and reassessment calendar.

## Guardrails

Do not treat a contract as sufficient without operational safeguards, use consent
as a routine substitute where invalid, or assume cloud location equals all access
locations. Verify current adequacy, clause versions, localisation, regulator
guidance, and destination law with qualified counsel.

Referenced files: 1

View saved version →

---
name: data-processing-agreement-reviewer
description: >-
  Review and draft data-processing agreements and privacy schedules for
  controller-processor, fiduciary-processor, joint-controller, service-provider,
  or independent-controller relationships. Use for instructions, security,
  breaches, subprocessors, assistance, transfers, audits, deletion, and liability.
---

# Data Processing Agreement Reviewer

Test the agreement against the actual service and data flow. Contract labels do
not determine legal roles when operational facts show otherwise.

## Intake

Obtain the main agreement, proposed DPA, parties and affiliates, service
description, data-flow and system diagrams, data and subject categories, purposes,
instructions, jurisdictions, hosting and access locations, subprocessors,
security materials, retention, incident process, audits, transfer mechanisms,
sector rules, insurance, and liability terms.

## Review method

1. Determine each party's role per processing purpose and identify independent,
   joint, processor, subprocessor, fiduciary, or other regulated activities.
2. Verify the processing schedule: subject, duration, nature, purpose, data,
   people, frequency, locations, retention, and controller instructions.
3. Test limits on use, sale, sharing, combination, profiling, advertising,
   product improvement, AI training, de-identification, re-identification, and
   independent purposes.
4. Review confidentiality, personnel access, training, screening, security
   measures, testing, certifications, evidence, and change controls.
5. Align incident definitions, immediate escalation, investigation cooperation,
   evidence, notice content, notification control, costs, and remediation.
6. Review subprocessor authorisation, current list, change notice, objection,
   equivalent obligations, location, flow-down, and primary responsibility.
7. Require proportionate assistance with rights requests, notices, DPIAs,
   consultations, records, audits, regulators, litigation holds, and complaints.
8. Map international transfers, onward transfers, approved mechanisms, annexes,
   government requests, supplementary safeguards, suspension, and updates.
9. Review retention, return, deletion, backups, legal holds, certification,
   transition, portability, and post-termination access.
10. Make audit and assurance rights operational, risk-based, non-duplicative,
    confidentiality-protected, and capable of escalating material gaps.
11. Reconcile privacy indemnities, liability caps, exclusions, insurance,
    precedence, termination, change control, and survival with the main agreement.

## Output

Provide a role and data-flow matrix, clause-by-clause issue list, operational-gap
schedule, proposed language, processing annex, security and subprocessor checklist,
transfer map, and negotiation priorities.

## Guardrails

Do not accept inaccurate roles, empty processing schedules, security promises
unsupported by evidence, blanket secondary use, or unworkable audit language.
Do not assume a DPA supplies lawful basis, notice, consent, or transfer compliance.
Verify current mandatory terms in every relevant jurisdiction.

Referenced files: 1

View saved version →

---
name: dpdp-compliance-checker
description: >-
  Assess a processing activity against India's Digital Personal Data Protection
  Act, 2023, Digital Personal Data Protection Rules, 2025, commencement
  notifications, corrigenda, exemptions, and sector rules. Use for India-facing
  notices, consent, rights, children, security, breaches, retention, or transfers.
---

# India DPDP Compliance Checker

Apply only provisions in force on the assessment date. The Act and Rules use
staggered commencement, so distinguish current duties from future readiness work.

## Intake

Obtain the assessment date, entities and roles, India nexus, data principals,
digital personal data and sources, purposes, systems, processors, consent and
notice flows, legitimate-use reliance, children or persons with disabilities,
security, breaches, retention, rights channels, grievances, transfers,
Significant Data Fiduciary status, exemptions, and sector obligations.

## Checking method

1. Build a commencement table from official notifications and state which Act
   sections, Rules, schedules, corrigenda, and Board functions are operative.
2. Confirm territorial and material scope, digital form, India offering nexus,
   exclusions, state or private roles, and any statutory exemption.
3. Map data flows by Data Fiduciary, Data Processor, Data Principal, Consent
   Manager, recipient, purpose, source, system, location, and retention.
4. Test each purpose for consent or an applicable legitimate use. Check free,
   specific, informed, unconditional, unambiguous affirmative action, withdrawal,
   burden, and verifiable records where consent is used.
5. Review notices for required items, clear language, standalone accessibility,
   rights and grievance routes, contact details, and consistency with operations.
6. Test accuracy where decisions or disclosures depend on data, data minimisation,
   purpose limitation, processor oversight, reasonable security safeguards,
   breach response, erasure, retention, and record evidence.
7. Assess rights workflows for access information, correction, completion,
   updating, erasure, grievance redressal, nomination, identity verification,
   response tracking, and appeal or escalation.
8. Apply current child and lawful-guardian requirements, prohibited processing,
   exemptions, and age or verification rules without guessing future obligations.
9. Determine whether Significant Data Fiduciary duties, DPO, auditor, DPIA,
   periodic audit, algorithmic due diligence, or other notified measures apply.
10. Review cross-border restrictions and sector localisation against current
    government notifications, not assumptions.
11. Rank current violations, implementation gaps, future commencement work,
    evidence needs, owners, and deadlines separately.

## Output

Provide the commencement table, scope and exemption analysis, data-flow register,
obligation-and-evidence matrix, notice and consent review, rights and grievance
assessment, security and breach gaps, transfer analysis, and remediation roadmap.

## Guardrails

Do not state that every Act or Rule provision is already effective, import GDPR
concepts as if they were DPDP text, or treat consent as universally required.
Verify official Gazette materials, corrigenda, Board notices, and sector rules
as of the assessment date with qualified Indian privacy counsel.

Referenced files: 1

View saved version →

---
name: dpia-documenter
description: >-
  Screen, conduct, and document data-protection or privacy impact assessments
  for new or changed processing. Use when evaluating necessity, proportionality,
  high-risk triggers, risks to people, automated decisions, sensitive data,
  children, monitoring, new technology, safeguards, and residual-risk approval.
---

# DPIA Documenter

Complete the assessment before high-risk processing begins and revisit it when
purpose, data, technology, scale, recipients, threat, law, or safeguards change.

## Intake

Obtain the proposal and decision owner, jurisdictions, processing purpose,
business outcome, data-flow and architecture, parties and roles, data and people,
sources, scale, frequency, matching, monitoring, profiling, automated decisions,
AI models, biometrics, children, locations, transfers, retention, security,
alternatives, prior assessments, incidents, and stakeholder views.

## Assessment method

1. Record the screening decision against current law, regulator lists, sector
   rules, and organisation thresholds. Explain both required and not-required outcomes.
2. Describe the full lifecycle: collect, generate, infer, combine, use, access,
   disclose, transfer, retain, archive, delete, and train or evaluate models.
3. Identify roles, legal bases or permissions, notices, consent, rights, contracts,
   secrecy, localisation, and governance dependencies.
4. Test necessity: connect each data element and operation to a specific outcome
   and identify less intrusive means.
5. Test proportionality: purpose compatibility, minimisation, accuracy, access,
   retention, transparency, choice, contestability, human review, and fairness.
6. Assess risk from the individual's perspective, including surveillance,
   exclusion, bias, denial of opportunity, manipulation, exposure, identity harm,
   financial loss, safety, confidentiality, autonomy, and chilling effects.
7. Score likelihood and severity before controls using explained criteria, not
   unsupported arithmetic.
8. Document existing and proposed technical, contractual, organisational, and
   product safeguards, evidence, owner, due date, and test method.
9. Reassess residual risk, record accepted assumptions and dissent, consult the
   DPO, security, legal, affected groups, representatives, or regulator as required.
10. Obtain accountable approval, conditions, launch gates, monitoring metrics,
    incident triggers, review date, and stop or reassessment criteria.

## Output

Provide the screening record, processing and data-flow description, stakeholder
consultation, necessity and proportionality analysis, risk register, safeguard
plan, residual-risk decision, approval record, and monitoring schedule.

## Guardrails

Do not use a DPIA to legitimise unlawful processing, hide unresolved high risk,
or substitute organisational impact for harm to people. Do not claim
anonymisation without technical evidence. Escalate residual high risk and obtain
required prior consultation before launch.

Referenced files: 1

View saved version →

---
name: privacy-policy-drafter
description: >-
  Draft and audit external privacy policies, collection notices, employee
  notices, child-facing notices, just-in-time notices, and layered disclosures.
  Use when notices must match verified processing, legal bases, sharing,
  transfers, retention, automated decisions, rights, and contact routes,
  including when Codex should inspect a website or application project and
  derive the processing inventory from its code, configuration, and dependencies.
---

# Privacy Policy Drafter

Draft from a verified data inventory and user journey, not a generic template.
A notice describes processing; it does not itself create a lawful basis or consent.

## Source selection

1. Check the current Codex workspace before requesting a URL or questionnaire.
2. If it contains website or application code, use project mode. Read
   [references/project-code-audit.md](references/project-code-audit.md) completely,
   inspect the project repository-wide, and derive an evidence-backed processing
   inventory. Do not ask for a URL unless no relevant code is available or the
   user wants deployed behaviour compared with the project.
3. If the workspace does not contain relevant code, use document or URL mode and
   obtain the data inventory from supplied materials, the deployed service, and
   targeted questions.
4. Treat code as evidence of implemented capability, not proof of every production
   practice. Separate confirmed facts, supported inferences, and unresolved facts.

## Intake

Derive as much as possible from the available project or source materials before
asking questions. Then obtain only the unresolved audience and jurisdictions,
organisation and roles, products and channels, data categories and sources,
purposes, legal bases or permissions, cookies and tracking, profiling and automated
decisions, recipients, sale or sharing concepts, transfers, retention, children,
security, rights, appeals, complaints, contact channels, prior versions, effective
date, and change process.

## Drafting method

1. Define each notice's audience, collection context, controller or fiduciary,
   scope, language, accessibility, delivery point, and relationship to other notices.
2. Map every disclosed data category to its source, purpose, legal basis or
   permission, recipient, transfer, retention rule, and rights impact.
3. Name categories in language meaningful to the audience; distinguish provided,
   observed, device, transaction, third-party, generated, and inferred data.
4. Explain purposes specifically enough to understand consequences. Separate
   service delivery, security, legal compliance, analytics, personalisation,
   advertising, research, and model training where applicable.
5. Describe recipients and onward use accurately, including processors,
   affiliates, partners, authorities, transaction counterparties, and public disclosure.
6. Explain international transfers, applicable safeguards, and how to obtain
   information where law requires.
7. State retention periods or useful criteria by data and purpose, including
   account closure, backups, disputes, legal holds, and deletion or de-identification.
8. Explain profiling, consequential automated decisions, human review, logic or
   significance where required, and available choices.
9. Present rights, withdrawal, objection, appeal, grievance, complaint, authorised
   agent, verification, accessibility, and response routes without deterring use.
10. Add child, employee, sensitive-data, cookie, mobile, camera, biometric, or
    other contextual disclosures only when the processing exists.
11. Cite project file paths and relevant implementation evidence in the working
    inventory, but keep source-code citations out of the public-facing notice.
12. Validate the draft with product, engineering, security, HR, marketing,
    procurement, support, and records owners before publication.

## Output

Provide the layered notice, short or just-in-time text, disclosure-to-inventory
matrix, unresolved fact list, localisation plan, publication checklist, version
record, and review triggers. In project mode, also provide the code-evidence
inventory and save or update the requested policy artifact in the project. If no
path is specified, choose a conventional documentation or site-content location,
avoid overwriting an existing policy without reviewing it, and report the path.

## Guardrails

Do not copy unsupported practices, promise absolute security, use blanket consent,
hide material processing, or say data is never shared when processors receive it.
Avoid dark patterns and vague future-use clauses. Verify current jurisdictional
notice content, language, timing, and accessibility rules before publication.
Do not expose secrets or personal data found in project files. Do not infer actual
production use, vendor contract terms, hosting location, retention periods, or
organisational identity solely from an integration, environment-variable name, or
unused code path. Mark such matters for confirmation and use conspicuous placeholders
when the user asks for a draft before they are resolved.

Referenced files: 2