Controller obligations

The controller obligations requirement in ISO/IEC 27701 means you must define, assign, and evidence the privacy-accountability duties of the organization acting as a controller, then run governance controls that prove those duties operate in day-to-day processing ¹. Operationalize it by documenting controller responsibilities, mapping processing, setting decision rights, and retaining audit-ready artifacts that show oversight and approvals.

Key takeaways:

• Write down who the controller is for each processing purpose, and who inside the company owns the controller decisions.
• Turn “accountability” into repeatable workflows: approvals, reviews, and documented outcomes for processing changes.
• Keep evidence that stands on its own in an audit: governance docs, decision records, and operating logs.

ISO/IEC 27701 extends an ISO 27001-style management system into privacy. For compliance operators, the practical implication is simple: auditors will not accept “we comply with privacy law” as a statement of intent. They will look for a controller accountability model that is explicit, assigned, and evidenced across the lifecycle of personal data processing ¹.

The controller obligations requirement is where many programs fail because the work is cross-functional and easy to leave informal. Product sets a purpose, Marketing wants new audiences, Security focuses on controls, Legal writes policies, Procurement negotiates third-party terms, and nobody maintains a single “controller decision record” that shows who approved what and why. ISO 27701 pushes you to make those decisions governable.

This page gives requirement-level implementation guidance for a Compliance Officer, CCO, or GRC lead who needs to stand up controller accountability quickly. It prioritizes concrete operating steps, clear ownership, and evidence you can produce on request, with minimal dependence on re-explaining privacy theory.

Regulatory text

Provided excerpt (summary-level): “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.” The implementation intent is: “Implement controls supporting controller accountability obligations.” ¹

What the operator must do: Build and operate documented governance that (1) clearly identifies controller responsibilities for processing activities, (2) assigns accountable owners and decision rights, and (3) produces durable evidence that controller decisions are made, reviewed, and approved consistently ¹.

Plain-English interpretation (what this requirement really asks)

You need a controller accountability operating model. That means:

• Your organization can demonstrate who acts as controller for each processing context (and when you act as processor).
• You can demonstrate who internally is authorized to make controller decisions (purposes, lawful basis/justification, disclosures, retention, sharing with third parties, handling data subject requests, and change approvals).
• You can demonstrate ongoing governance, not a one-time documentation exercise: regular reviews, tracked decisions, and change control.

Think of this as the privacy equivalent of “security ownership and risk acceptance.” If a processing activity creates risk, someone with controller authority must approve it, and you must be able to show that approval later.

Who it applies to (entity + operational context)

Applies to:

• Organizations acting as a data controller for any personal data processing in scope of the privacy program ¹.
• It can also affect processor operations, because your internal teams must know when you are controller vs processor, and apply the correct governance path ¹.

Operational contexts where this shows up immediately:

• Launching or changing products/features that collect personal data.
• Marketing and analytics changes (new tracking, new audiences, new data sources).
• HR/employee data processing changes.
• Introducing a new third party (or new data flow) where you decide purposes/means.
• Data retention changes, new sharing arrangements, cross-border data handling decisions (handled as governance decisions even if the underlying legal analysis happens elsewhere).

What you actually need to do (step-by-step)

1) Define the controller accountability model (document + RACI)

Deliverable: Controller Responsibilities & Governance Standard (one doc, versioned). Include:

• How your company determines whether it is acting as controller, joint controller, or processor for a given activity (keep it practical: a short decision rubric).
• A RACI that assigns “Accountable” roles for controller obligations (commonly Privacy Officer/DPO equivalent functionally, Legal, Product owner, Security, Records/IT, Procurement, and business owner).
• A list of decisions that require controller sign-off (examples below).

Controller decisions that should require sign-off (adapt to your environment):

• New processing purpose or material change in purpose.
• New categories of personal data, sensitive data, or new data sources.
• New disclosures or privacy notice changes.
• New sharing with a third party, or new onward transfer pattern.
• Retention schedule exceptions.
• High-risk processing approval path (however you define it internally).

2) Build and maintain a processing inventory aligned to controller responsibilities

Deliverable: Processing register that ties each processing activity to:

• Business owner (accountable)
• Purpose (what it is for)
• Systems involved
• Data categories
• Third parties receiving data
• Retention rule owner
• Related policies/standards and approvals

This is the backbone artifact that lets you prove controller accountability is not scattered across emails and meetings.

3) Implement a controller decision workflow (intake → review → approval → record)

Deliverable: Controller Decision Log plus a workflow in your GRC/ticketing tool. Minimum viable workflow:

1. Intake form for new/changed processing (initiator: Product/Marketing/HR).
2. Triage for controller vs processor classification.
3. Required reviewers (Privacy/Legal, Security, and the business controller owner).
4. Decision outcome recorded (approve, approve with conditions, reject, defer).
5. Conditions tracked to closure (e.g., update notice, add DPA terms, change retention config).

Practical tip: keep the intake short. If it takes too long, teams route around it and you lose evidence.

4) Tie third-party onboarding to controller accountability

If you are controller and a third party processes personal data on your behalf, your governance must show:

• The business owner requested the third party.
• Privacy requirements were assessed and approved.
• The sharing is recorded in the processing register.
• The contract path is mapped (DPA or equivalent terms handled by Legal/Procurement) and the execution is recorded as evidence.

This is where many programs break: the security review exists, but the controller decision (why we share, what purpose, what retention, what notice coverage) is not recorded.

5) Operationalize ongoing oversight (cadence + triggers)

Deliverable: Controller governance calendar and defined triggers.

• Cadence review: periodic review of the processing register and decision log for completeness, stale entries, and unclosed conditions.
• Trigger reviews: new product launch, major vendor change, incident involving personal data, new data source, or material policy change.

Even a lightweight cadence is enough if it is consistent and documented.

Required evidence and artifacts to retain (audit-ready)

Keep artifacts that answer: “Who decided, based on what information, and what happened afterward?”

Core artifacts

• Controller Responsibilities & Governance Standard (version history).
• RACI / role descriptions for controller decision-makers.
• Processing register (current export + change history).
• Controller Decision Log (tickets or records showing reviewer/approver identities and outcomes).
• Evidence of operating cadence (meeting agendas, minutes, sign-off records, dashboard snapshots).

Change-control artifacts

• Records of processing changes routed through the workflow.
• Proof that conditions were implemented (e.g., updated privacy notice approval record; retention configuration change record; third-party contract executed).

Third-party artifacts (where applicable)

• Third-party intake and approval records tied to a processing activity.
• Contract/DPA execution records (or at minimum, contracting checklist completion record).
• Data sharing summaries mapped to the processing register.

Common exam/audit questions and hangups

Auditors and assessors tend to press on these points under the controller obligations requirement ¹:

• “Show me how you determine when you are controller vs processor.”
• “Who is accountable for approving a new processing purpose?”
• “Pick three processing activities. Show the approval trail for each.”
• “How do you ensure your processing register stays current?”
• “How do third-party onboarding and contracting connect to controller governance?”
• “Where is evidence that privacy requirements were considered before launch, not after an incident?”

Hangup to expect: teams may produce policies but not decision records. ISO-style audits reward traceability.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails audits	Fix
Treating accountability as a policy-only exercise	Policies don’t prove operation	Add a decision workflow + decision log tied to processing changes
Processing inventory exists but lacks owners/approvals	No accountable controller trail	Require accountable owner and approval references per processing activity
Third-party reviews focus only on security	Controller purpose/means decisions are missing	Add controller sign-off fields: purpose, data categories, sharing justification, retention
Decisions happen in email/Slack	Evidence is fragmented and not durable	Centralize approvals in tickets or a GRC workflow
No closure on “approve with conditions”	Conditions become permanent debt	Track conditions as tasks with owners and closure evidence

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, your risk is still clear: weak controller accountability creates gaps where processing expands without proper approvals, notices, retention alignment, or third-party controls. The first time you need to respond to a regulator, customer, or auditor, you will be reconstructing decisions after the fact instead of producing a clean record.

Practical 30/60/90-day execution plan

Days 0–30: Stand up the minimum viable accountability system

• Publish a Controller Responsibilities & Governance Standard with a clear controller vs processor decision rubric ¹.
• Define and socialize a RACI for controller decisions; get written acceptance from accountable leaders.
• Create a processing register template and populate the highest-risk/highest-volume processing activities first (focus on systems and products that move the most personal data).
• Implement a single intake workflow (ticket form) for new/changed processing with required approvers.

Days 31–60: Connect it to operational change paths

• Integrate intake into product launch and marketing change processes (release checklist, campaign checklist, or change management gates).
• Tie third-party onboarding to the same workflow: no new third party receives personal data without a processing register entry and controller sign-off.
• Start the Controller Decision Log and enforce: approvals must live in the system of record, not email.

Days 61–90: Prove it operates and harden evidence

• Run a cadence review of the processing register; document findings and remediation actions.
• Sample completed decisions and verify artifacts are complete: intake, reviewers, outcome, conditions closed.
• Build an audit packet: export processing register, decision log sample set, governance doc versions, and cadence evidence.
• If you use Daydream, configure it as the system of record for controller governance artifacts and approvals so you can produce an assessor-ready evidence bundle without scrambling.

Frequently Asked Questions

What is the simplest way to satisfy the controller obligations requirement without boiling the ocean?

Write down controller responsibilities and decision rights, then route all new or changed processing through a single approval workflow with a durable decision record ¹. Start with the processing activities that carry the most operational exposure.

Do we need to be a “data controller” all the time for this to apply?

No. You need a reliable way to determine when you are acting as controller versus processor, and you must apply controller accountability controls when you are the controller ¹.

What evidence is most persuasive to an ISO 27701 auditor?

Decision records tied to real processing changes: intake, reviewers, approvals, and closure of conditions. A processing register with named owners and traceable approvals usually carries more weight than narrative policy statements alone.

How do we handle joint controller or ambiguous situations operationally?

Treat ambiguity as a trigger for documented classification and sign-off. Record the rationale and who approved the classification in the decision log, then map the accountability and external arrangement into the processing register.

Our teams approve things in Slack. Can we keep doing that?

You can, but you still need a system of record. Add a rule that the final decision and approver identity must be captured in the ticket/GRC workflow, with Slack used only for discussion.

Where does third-party risk management fit into controller obligations?

If a third party processes personal data for your purposes, controller accountability requires you to document why you share, who approved it, and where it is recorded in your processing inventory. Security review alone rarely covers those controller-specific decisions.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. ISO/IEC 27701 overview