Privacy

The Privacy module governs your organization’s privacy posture: the processing activities you perform on personal data, the impact assessments you’ve conducted, the data subject requests you’ve responded to, the processors you’ve engaged, and the cross-border transfers you’ve documented. It is framework-agnostic by design — the same module supports GDPR’s records of processing, CCPA’s accountability requirements, sectoral healthcare privacy regimes, and any internal privacy program.

This module is not a consent management platform, a cookie banner, a data discovery tool, or a data subject request automation system. It is the governed register that surrounds those operational tools.

When you would reach for this

You set up privacy when:

• A privacy regime (or several) requires you to maintain records of processing activities.
• Data protection impact assessments (DPIAs, PIAs) need a governed record with reviewer sign-off.
• Data subject requests (access, deletion, portability, objection) need an auditable response trail.
• Processor relationships need formal records linked to contracts and assurance.
• Cross-border data transfers need documented mechanisms (standard contractual clauses, adequacy decisions, binding corporate rules).

You don’t reach for this for the operational handling of a specific subject request, the operational redaction work, or the actual data flows. Privacy here is the governed record of the discipline.

What lives in the module

Five record types:

• Processing activity captures one named activity that processes personal data: the purpose, the data categories, the lawful basis (where applicable), the recipients, the retention, the systems involved.
• DPIA (data protection impact assessment) captures a structured assessment of a high-risk processing activity: scope, risks, mitigations, residual risks, conclusions.
• Data subject request captures one received request from a data subject, with response progress, deadline, and outcome.
• Processor record captures one processor relationship: provider, scope of processing on the controller’s behalf, contractual basis.
• Transfer record captures one cross-border data transfer arrangement: jurisdictions involved, mechanism, safeguards.

A worked example: a digital advertising platform governs its privacy posture

A digital advertising platform handles personal data at scale: ad impressions, user interactions, audience segmentation, advertiser reporting. It operates under multiple privacy regimes simultaneously depending on user residence and processing context. The data protection officer, Mateo, sets up Privacy like this.

Step 1: inventory processing activities. Each named activity is a record:

• audience-segmentation — segmenting users for advertiser targeting.
• ad-delivery — serving ads based on user context.
• attribution-reporting — reporting conversions back to advertisers.
• user-account-management — handling registered user accounts.
• internal-analytics — internal product analytics on platform usage.

Each activity captures purpose, data categories, lawful basis (legitimate interest for some, consent for others), recipients, retention, systems.

Step 2: DPIAs for high-risk activities. Activities involving systematic monitoring, large-scale processing of sensitive categories, or new technology trigger DPIAs. Mateo conducts DPIAs for audience-segmentation (large-scale profiling) and for a new feature using behavioral signals. Each DPIA captures: scope, risks, mitigations, residual risks, conclusions, sign-off.

Step 3: data subject requests. Each request received from a user (access, deletion, correction, portability, objection, opt-out) becomes a record. The request walks through receipt, identity verification, scope assessment, response preparation, response delivery. The deadline (e.g., 30 days in some regimes) is tracked; the response artifact is attached.

Step 4: processor records. The platform uses sub-processors: a fraud detection service, a CDN, a managed analytics warehouse. Each sub-processor is a record: scope of processing on behalf of the platform, contractual basis (DPA), assurance records, the party engagement that wraps it.

Step 5: transfer records. Personal data moves across borders: from EU users to the platform’s US-based analytics service, from APAC users to similar processing, to sub-processors in various jurisdictions. Each transfer is a record: source jurisdiction, destination jurisdiction, mechanism (SCCs, adequacy, BCRs), safeguards (encryption, contractual restrictions), the activity it relates to.

After a year:

• The records of processing are kept up to date as activities evolve.
• Subject requests are tracked from receipt to response, with deadlines surfaced.
• Processor relationships have formal records connected to contracts.
• Transfer mechanisms are documented per jurisdiction pair.
• A regulator (or a customer’s privacy team) can be shown the program in one place.

What you’ll see in the product

Privacy lives under Governance → Privacy in the workspace.

Five top-level tabs: Processing Activities, DPIAs, Data Subject Requests, Processor Records, Transfer Records.

Every change is captured in the workspace Audit Log.

Common workflows

Inventorying processing activities

1. Processing Activities → New. Capture purpose, data categories, lawful basis, recipients, retention, systems.
2. Review periodically as the program evolves.

Running a DPIA

1. DPIAs → New. Pick the activity being assessed.
2. Walk the methodology: risks, mitigations, residual risks, conclusions.
3. Route for sign-off.

Handling a subject request

1. Data Subject Requests → New. Capture identity (or verification path), the request type, scope.
2. Walk receipt → verification → assessment → response.
3. The deadline is tracked; the response is attached.

Documenting a transfer

1. Transfer Records → New. Source, destination, mechanism, safeguards.
2. Link to the affected processing activities.
3. Review when the mechanism changes (e.g., a new adequacy decision lands).

Related

• Party Engagements - processors are typically party engagements.
• Obligations - privacy obligations live in the obligation register.
• Evidence - DPIA outcomes can be evidence.
• Findings - privacy gaps surface as findings.
• Risks - privacy risks live in the risk register.