Run privacy operations without a separate spreadsheet
Maintain your record of processing, review a data flow register seeded from the integrations you've already connected, track data subject requests against a statutory clock, and turn a DPIA into a real, linked entry in your risk register — all in the same workspace as the rest of your compliance program.
What it does
Records of Processing (RoPA)
Maintain an Article 30 register: name, controller-or-processor role, purpose, lawful basis, data categories, retention, and recipients per activity.
Data flow register
Track where personal data moves between systems, the data categories involved, lawful basis, and whether a transfer crosses a border, with a safeguard noted.
Integration-seeded suggestions
Draft data flow entries are proposed from the integrations you've already connected, so you start from what's actually wired up, not a blank form. You review and explicitly accept each one — this is not automated discovery of what data those systems actually move.
DSR intake & tracking
Log access, deletion, portability, and opt-out requests with the subject's email, received date, and an assignee.
30-day SLA clock
Every DSR gets a due date under the GDPR Art. 12(3) one-month clock, with due-soon and overdue states so nothing quietly lapses.
DPIA workflow
Capture the processing description, necessity and proportionality justification, risks to individuals, and mitigating measures for a DPIA.
DPIA-to-risk linkage
Submitting a DPIA creates a real entry in your risk register at a likelihood/impact derived from the residual risk level you assess (low, medium, or high) — DPIAs live on the same 5x5 heat grid as every other risk, not in a separate database.
Link to RoPA
Associate a DPIA with the processing activity it assesses, so the assessment and the record it's about stay connected.
One evidence graph
RoPA, data flows, DSRs, and DPIA-linked risks sit alongside your controls and evidence, keeping privacy work visible across the rest of the platform.
From setup to proof
Step 1
Record processing activities
Log each processing activity with its purpose, lawful basis, data categories, and retention, building your Article 30 record as you go.
Step 2
Review suggested data flows
See draft data flow entries proposed from your connected integrations, and accept, edit, or dismiss each one — nothing is added without your review.
Step 3
Log and track DSRs
Record each data subject request on intake and watch it against a 30-day SLA clock, with due-soon and overdue states visible at a glance.
Step 4
Run a DPIA
Document processing, necessity, risks to individuals, and mitigations, then submit it — the assessment becomes a linked entry in your risk register at the residual risk level you set.
Step 5
Keep it current
Update processing activities, flows, and DSR statuses as your data map and third parties change, instead of a document that goes stale.
Privacy work that’s actually tracked
Article 30, kept current
A record of processing you maintain, not reconstruct
GDPR requires most organizations to keep a record of their processing activities. Rather than a document someone updates twice a year, each activity — purpose, lawful basis, data categories, retention, recipients, and whether you're the controller or a processor — lives as a row you can add to and edit as your processing actually changes.
- Purpose, lawful basis, and data categories per activity.
- Controller or processor role recorded explicitly.
- Retention and recipients captured alongside each entry.
- Editable as processing changes, not a point-in-time document.
Start from what's connected, not a blank sheet
A data flow register seeded by your real integrations
Mapping where personal data moves is normally the hardest part of a privacy program to start. Draft data flow entries are proposed from the integrations you've already connected in GRC Oversight, so you begin from your actual system inventory. Each suggestion is explicit and reviewer-driven: you accept, edit, or dismiss it — the platform does not infer what fields a connector syncs or auto-populate flows without your say-so.
- Draft flows proposed from your connected integrations, one suggestion per system.
- You explicitly accept, edit, or dismiss each suggestion before it's recorded.
- Track data categories, lawful basis, and cross-border transfers with a safeguard.
- Not automated discovery of what personal data a system actually moves — you fill in and confirm the specifics.
The clock that matters most
DSR tracking against a real statutory deadline
A data subject request has a legal clock attached to it. Every request you log gets a due date under the GDPR Article 12(3) one-month standard, and the register surfaces which requests are on track, due soon, or overdue, so a request doesn't get missed because it was sitting in someone's inbox.
- Access, deletion, portability, and opt-out request types.
- 30-day due date set automatically from the received date.
- Due-soon and overdue states visible without digging.
- An assignee and notes recorded on every request.
One risk model, not two
DPIAs that become real, linked risks
A DPIA that identifies a risk is supposed to result in a decision about that risk, not a document that sits apart from how you actually manage risk. Submitting a DPIA here creates an entry in your existing risk register — same register, same heat grid — scored from the residual risk level you assess, with the DPIA's narrative (processing description, necessity justification, risks to individuals, mitigations) attached to it. There's no separate DPIA database to keep in sync with the risk register; the DPIA is the risk.
- DPIA answers become a structured, linked risk register entry.
- Residual risk level (low/medium/high) sets the likelihood and impact score.
- Shows up on your existing risk heat grid alongside every other risk.
- Optionally linked to the RoPA entry the DPIA assesses.
For the team that owns GDPR accountability
Building your Article 30 record
Stand up a real record of processing activities instead of a spreadsheet someone updates once a year.
Mapping data flows from real connectors
Start your data flow register from the integrations you've already connected instead of interviewing every team from scratch.
Handling a subject access request
Log the request, track it against the 30-day clock, and hand off with an assignee and notes attached.
Assessing high-risk processing
Run a DPIA before launching new processing that's likely to result in high risk to individuals, and get a linked risk entry out of it.
Demonstrating accountability
Show a regulator or an enterprise customer a current RoPA, a reviewed data flow register, and a DSR log with SLA tracking.
Keeping privacy in the same risk model
Avoid a parallel privacy risk register — DPIA-derived risks sit in the same register your security and compliance risks already live in.
Privacy accountability you can show your regulator
Capability and direction, built honestly, proven by your own evidence as deployments land.
- A current Article 30 record of processing activities, not a stale document.
- A data flow register you can defend, seeded from real connectors and reviewed by you.
- Every data subject request tracked against a real statutory deadline.
- DPIAs that produce a real, scored risk entry, not a form that goes in a drawer.
- Privacy work sitting in the same evidence graph as the rest of your compliance program.
Privacy that isn’t a separate tool
The product choices that matter when this workflow becomes part of your audit engine.
Seeded, not blank
Data flow drafts start from integrations you've already connected in the platform, so mapping doesn't begin from a blank form — though you still confirm every field.
You review every suggestion
Nothing from the integration inventory is recorded as a data flow until you explicitly accept it. No silent auto-population.
A real deadline, not a note
DSRs carry an actual due date under the GDPR Art. 12(3) standard, with urgency states instead of a manual tickler.
One risk register, not two
DPIAs create real Risk entries scored on the same heat grid as the rest of your program, so privacy risk isn't tracked apart from everything else.
Questions, answered
Does the data flow register discover data automatically?
No. It proposes draft entries from the integrations you've already connected in GRC Oversight (e.g. "your organization → Google Workspace"), flagged for you to review. You explicitly accept, edit, or dismiss each suggestion and fill in the real data categories and lawful basis — it does not inspect or auto-detect what personal data a connector actually syncs.
Is there a dedicated DPIA database?
No. A submitted DPIA is created as an entry in your existing Risk register, tagged as a DPIA, with the residual risk level you select setting its likelihood and impact score. The DPIA's narrative (processing description, necessity, risks, mitigations) is attached to that risk. This keeps DPIAs and risk management as one source of truth instead of two registers that can drift apart.
How is the DSR due date calculated?
Each data subject request gets a due date 30 days from when it was received, following the GDPR Article 12(3) one-month standard. You can also set a custom due date if a different deadline applies. The register shows due-soon and overdue states so requests don't lapse unnoticed.
Can I link a DPIA to a RoPA entry?
Yes. A DPIA can reference the processing activity it assesses, so the assessment stays connected to the record of processing it's about.
Does this replace legal advice on GDPR compliance?
No. This tracks the operational record-keeping and workflow GDPR expects (RoPA, data flows, DSR handling, DPIAs) — it doesn't provide legal determinations about lawful basis, applicability, or whether a specific DPIA is required.
Related products
Ready to prove trust continuously?
Get a guided demo, or start by scanning any domain for free.