The challenge with controls that sit between security and privacy isn’t just naming a department in a spreadsheet. It’s making sure someone acts when an access review is incomplete, a deletion doesn’t reach backups, or an incident requires both technical containment and a data‑protection assessment. Labels like “IT and Privacy” often result in two teams involved but no one accountable for the state of the control.
What prevents that vacuum is a recognisable operational owner supported by executors, decision‑makers and verifiers with clearly defined responsibilities. That assignment must appear in the evidence: approved requests, test results, tracked exceptions and closed remediation actions. Below is a practical method applied to three common shared controls where handoffs typically create ambiguity, without rebuilding a full RACI matrix.
Who should be the owner (and what does ownership mean?)
The operational owner of a control is not necessarily the legal data controller nor a statutory role mandated by regulation. It is the person responsible for keeping the control working: they understand the scope, coordinate contributors, ensure evidence is available and escalate anomalies to decision‑makers.
The GDPR (see Articles 5, 24, 32, 38 and 39) sets out principles of accountability, security measures and DPO tasks. The internal ownership model described here is an organisational choice to make those safeguards verifiable in practice; it does not transfer regulatory responsibilities away from the data controller. Designating someone as an “owner” is an operational step, not a legal reassignment of accountability under law.
A useful rule: assign ownership to someone who can drive the entire control cycle. If the person can only request information and cannot obtain it or trigger escalation, the assignment is weak. In that case either give them a concrete mandate or split the control into linked activities, each with its own owner.
Also remember the DPO’s independence and advisory role. The DPO should not automatically be the executor, approver and verifier of every activity touching personal data; governance must preserve impartiality and avoid conflicts of interest.
Define the scope and expected result before you pick a name
Labels such as “Access Management” are too broad to be audited. “Quarterly review of CRM user accounts, including vendor accounts” is an observable activity with a start, defined scope and expected outcome. Frequency is an operational choice, not a regulatory mandate.
For each shared control, first describe the demonstrable result, then identify who holds the levers to achieve it. A short operational card for the control should include:
- Scope: systems, processing activities, user categories and dependencies.
- Operational owner: named person, organisational role and deputy.
- Required contributions: who executes, who approves exceptions and who verifies outcomes.
- Expected evidence: documents or logs, covered period and acceptance criteria.
- Handoff conditions: delivery criteria, recipient and escalation path.
The handoff description is often the most important. “Send the report to Privacy” doesn’t clarify what happens next; “Privacy confirms that authorisations align with processing purposes; IT revokes rejected accesses and records the outcome” describes a verifiable sequence.
The card must be accepted by the involved roles. A unilateral entry in a spreadsheet does not prove that the person accepted the assignment or has access to the necessary information.
Three shared controls and where ownership matters
The examples below illustrate how to separate technical execution from process decisions and final verification. Roles should be adapted to your organisation’s size and the actual powers assigned.
Access reviews: who decides and who revokes
Imagine a CRM containing customer and contact data. The system administrator can extract user accounts but may not know whether each permission is justified. The process owner (e.g., sales manager) can confirm the business need for access but may lack authority to revoke accounts.
A practical split: an operational owner who coordinates the review, a process owner who evaluates necessity, and a technical executor who implements changes.
Evidence of closure must link the initial state to decisions and the final state, for example:
- Extraction of accounts: system administrator — dated export with extraction criteria.
- Assessment of access necessity: process owner — decisions mapped to users and permissions.
- Revocations/changes applied: technical executor — ticket(s) and updated account status.
- Completion verification: designated verifier — reconciliation between approved decisions and technical changes.
The operational owner remains responsible for coordination up to verification. If three revocations are still pending, the control is not complete simply because the process owner approved the list. Apply consistent criteria to distinguish available documents from audit‑quality evidence; see /en/blog/evidence-for-audit on practical approaches.
Deletions and backups: avoid two definitions of “completed”
A deletion request can be marked complete in the primary application while copies, exports or backups still contain the data. Application teams and infrastructure teams may adopt different completion criteria, leaving no single responsible party for end‑to‑end removal.
Start by inventorying all copies within scope and those handled via separate processes. The data controller (or processing owner) defines the required outcome with technical support; application and infrastructure teams document how they realise it. The lawfulness of retention periods and deletion methods is a separate assessment that cannot be solved by a purely technical choice.
The owner must obtain explicit confirmation about residual copies. “The data no longer appears in the UI” does not prove completeness.
Evidence may include: application deletion results, an inventory of copies, backup retention rules and a tested restore procedure showing how deleted data would be handled if restored. If any component prevents the required result, the owner should open a remediation action specifying scope, responsible party and verification criterion. Don’t close the control with a vague “technical limitation” note or rely on an internal risk acceptance as proof of compliance.
Incidents: separate containment from privacy assessment
During an incident, security and privacy both need the same facts but different answers. The technical team must understand what happened and contain the event; the privacy function must assess consequences for personal data and trigger any required notification or mitigation steps.
Not every IT incident is a personal data breach. Guidance on personal data breaches and obligations is available under GDPR; the concrete assessment must be performed by competent people, not inferred automatically from the technical classification alone.
The incident owner coordinates factual collection. The initial dossier should indicate potentially affected systems and data, time window, subjects involved and outstanding checks. It must distinguish confirmed facts from hypotheses so decisions are not taken on provisional data presented as certain.
The handoff to privacy should be logged: who received the dossier, when, what additional information was requested and what decision followed. Technical closure of containment does not equal closure of privacy assessments or remediation.
When a control fails, ownership must remain visible
The critical moment is not the initial assignment but the management of anomalies. A control can have a formally correct owner but lose accountability when the problem is handed off to another team or an external provider.
The control owner and the remediation owner may be different people. The first maintains visibility on coverage and residual risk; the second performs the assigned corrective work. Handover must keep the link between them.
For example, an access review finds former employees still active. The review owner opens a finding and documents scope. A designated administrator revokes the accounts. The verifier checks that the accounts from the original list are disabled and that evidence covers the original set, not a selective sample chosen after the fix.
Closure must be justified against the detected defect. A ticket marked “resolved” is insufficient without a record of the intervention and the evidence link. If the fix changes the control, update the procedure, scope and ownership card.
Changes of assignment should be dated and include an explicit transfer of open tasks. Good audit‑trail practices help reconstruct who changed status, which evidence was used and why the problem is considered closed; see /en/blog/audit-trail-best-practices for guidance.
If automation intervenes, assign error‑recovery ownership too
Automated workflows can create tickets or propose incident classifications, but that does not remove the need to identify who checks results, corrects errors and manages cases the automation cannot resolve.
Even when AI supports security and privacy processes, ownership must include error recovery. If a request is routed to the wrong team, the responsible party for correction, the escalation path and handling of pending items must be clear.
Include the human decision that corrects or confirms automated outcomes in the evidence pack. An automated output alone does not prove who took the operational decision. See this analysis of trust and ownership in AI workflows: https://aiproduct.cards/blog/why-ai-trust-fails-when-errors-have-no-clear-owner
Building an evidence pack an auditor can rely on
To test your setup, pick a real control and reconstruct its last execution: start from the ownership card, follow contributions from each team and end with completion evidence. If you have to narrate who authorised an exception in a meeting rather than show a recorded decision, the dossier is probably incomplete.
A robust evidence pack for shared security and privacy controls should answer four questions: who coordinated the activity, who could decide, who executed the intervention and who verified the result. You don’t need duplicate documents for each function; you need to link the same evidence to relevant controls while preserving context and access controls.
Before an audit, confirm the owner is still in role, a deputy is assigned and open exceptions have deadlines. A control that looks “green” may in reality have partial coverage; the dossier must make that visible rather than hide it behind a status indicator.
This approach makes ownership verifiable over time. To embed it in broader compliance efforts, keep requirements, controls, test results and decisions about anomalies distinct; see /en/blog/gdpr-audit-demonstrable-compliance for practical pathways.
Frequently asked questions
Is a single owner always required for each control? A single operational owner is a useful convention to prevent coordination gaps, not a legal imperative. Complex controls can have owners for subcomponents with a single accountable owner for the overall outcome.
What if IT and Privacy disagree about closure? Escalate to the governance role with decision authority under your internal rules. Log the dispute, available evidence and the final decision; do not treat silence by one function as tacit approval.
Can the same person execute and verify a control? Separation increases independence. If resources are limited, document the limitation and require a proportionate review by another role, especially for higher‑risk activities. Do not present self‑verification as independent assurance.
Making the assignment operational with AuditReady
AuditReady centralises evidence with ownership metadata, versioning and audit trail capabilities, and helps manage controls, findings and remediation. To apply this model to your controls, evaluate AuditReady for GDPR controls at /en/auditready/lp/gdpr — start with one control and its last execution cycle.
AuditReady evidence pack demo / not legal advice