Joint Controller Governance: GDPR Article 26 Audit Guide
The call came on a Tuesday morning. For the CISO at CareConnect, a fast-growing MedTech SaaS provider, it was the moment the ground shifted.
On the other end was the Head of Compliance from MetroHealth, their flagship hospital partner. A patient using their jointly managed remote monitoring platform had submitted a data subject access request a month earlier. Neither organization had fully responded. Each believed the other was responsible.
Then Legal forwarded a second message. A junior developer at CareConnect had accidentally exposed a non-critical API endpoint that included limited patient identifiers. The issue looked containable, and the GDPR 72-hour breach notification window had not yet closed. But the same question froze both teams.
Who informs the supervisory authority? Who communicates with patients? Who owns the privacy notice? Who validates the data subject request? Who records the decision?
The commercial agreement was detailed on service credits, invoicing, liability caps, and product roadmap milestones. It was almost silent on the operational reality of GDPR Article 26 joint controller governance.
This is where many partnerships fail. The issue is not that privacy, legal, security, and procurement teams have never heard the phrase “joint controller arrangement.” The issue is that nobody can prove, before processing begins, who is responsible for transparency, lawful basis, PII principal rights, breach escalation, supplier flow-downs, transfers, retention, evidence, and regulator communication.
GDPR defines the obligation. ISO/IEC 27701:2025 gives privacy teams a management-system structure. Clarysec’s PIMS policies, the Zenith Blueprint: An Auditor’s 30-Step Roadmap, and Zenith Controls: The Cross-Compliance Guide turn Article 26 into audit-ready operating evidence.
Why joint controller governance fails before anyone notices
A joint controller relationship exists when two or more parties jointly determine the purposes and means of personal data processing. The trigger is not the wording of the contract. It is decision-making power.
In the CareConnect and MetroHealth example, CareConnect provides the platform, analytics, technical architecture, user interface, and data flows. MetroHealth provides the patient relationship, clinical context, service model, and patient data. Both influence why personal data is processed and how the processing works. That is very different from a vendor merely hosting a database or sending messages on documented instructions.
The same pattern appears in financial wellness campaigns, embedded insurance partnerships, online marketplaces, fraud detection consortia, connected health platforms, loyalty programs, identity verification ecosystems, and analytics collaborations. A bank, insurer, and SaaS platform might jointly decide target segments, profiling rules, conversion metrics, and marketing channels. A processor data processing agreement will not solve that problem if the parties are actually joint controllers.
The practical failures are predictable:
- The privacy notice says little more than “we may share data with partners.”
- The processing inventory identifies parties but not the allocation of obligations.
- The data subject rights workflow has no route for forwarding, validating, or answering requests.
- The incident plan says “notify Legal” but not which joint controller leads external communication.
- The contract is treated as commercial paperwork, not accountability evidence.
- Termination provisions do not cover data return, deletion, anonymization, access removal, or evidence preservation.
GDPR Article 5 makes these failures audit-sensitive because controllers must not only comply with principles such as lawfulness, fairness, transparency, purpose limitation, minimization, accuracy, storage limitation, integrity, confidentiality, and accountability. They must be able to demonstrate compliance. Article 6 adds the lawful basis requirement. Article 3 can bring non-EU SaaS, fintech, health-tech, and analytics providers into scope when they offer services to individuals in the EU or monitor their behavior.
The lesson for CISOs and compliance managers is direct: joint controller governance is not “just Legal.” It is a cross-functional control system involving privacy, security, procurement, product, engineering, support, incident response, marketing, and executive oversight.
The ISO/IEC 27701:2025 PIMS principle: decide before processing starts
An ISO/IEC 27701:2025 Privacy Information Management System works only if privacy roles are determined before processing begins. This is the operational discipline that stops Article 26 from becoming a post-incident reconstruction exercise.
Clarysec’s Privacy Information Management System Policy, clause 4.2.2, states:
[Joint Controller] The Vendor / Procurement Owner MUST document joint controller responsibility allocation in REG08 before joint processing begins.
The phrase “before joint processing begins” is the control point. It means before the platform integration goes live, before the shared dashboard is enabled, before CRM synchronization starts, before campaign audiences are activated, and before data subject requests begin arriving.
The supporting inventory obligation appears in the PII Processing Inventory and Lawful Basis Policy, clause 4.3.5:
[Joint Controller] The Vendor / Procurement Owner MUST record the joint controller processing purpose and responsibility allocation reference in REG02 and REG08 before joint controller processing begins.
Together, these clauses create the evidence chain auditors expect:
- REG02 records the processing activity, purpose, data categories, lawful basis, retention, systems, recipients, transfers, and joint controller reference.
- REG08 records the joint controller arrangement and responsibility allocation.
- REG07 records the public-facing transparency summary.
- REG06 can record rights request intake, routing, validation, deadlines, and response evidence.
- REG10 records incident and breach assessment decisions.
That chain turns Article 26 from a legal statement into a management-system process.
Start with scope, stakeholders, and a RACI
The Zenith Blueprint starts with scope and stakeholders because joint controller governance fails when interested parties and requirements are identified too late.
In the ISMS Foundation & Leadership phase, Step 2, Stakeholder Needs and ISMS Scope, the Zenith Blueprint recommends a stakeholder analysis that captures explicit and implicit requirements:
How to identify needs and expectations: For each stakeholder group identified, list what they
require with respect to information security. Some requirements are explicit (laws, contracts,
SLAs), while others are implicit (expectations or general good practices). It helps to:✓ Review legal and regulatory requirements applicable to your context (from Step 1’s
context analysis). Make a list of specific clauses or obligations related to information
security or privacy.
✓ Review contracts and agreements : Many business contracts have confidentiality or
security addendums. Extract those requirements.
✓ Conduct stakeholder interviews or workshops : Engage with representatives from
each group (e.g., an HR manager for employee perspective, a sales manager for client
expectations) to understand their concerns or needs.
✓ Consider industry standards or codes of practice that stakeholders expect you to
follow.
For an auditable GDPR Article 26 joint controller arrangement, the interested-party analysis should include customers, patients, users, supervisory authorities, the other controller parties, processors, subprocessors, insurers, cloud providers, internal departments, regulators, and management bodies.
Step 4, Roles and Responsibilities in the ISMS, then turns that analysis into ownership. The Zenith Blueprint highlights the value of a RACI model:
✓ Accountability vs. Responsibility: A useful tool here is a RACI matrix (Responsible,
Accountable, Consulted, Informed). For each major ISMS process or control, identify
who is Responsible (does the work), who is Accountable (ultimately answerable, often a
manager), who is Consulted (provides input), and who is Informed.
For joint controllers, the RACI is not optional in practice. Without it, Legal assumes Privacy is answering the request, Privacy assumes Support has the intake queue, Support assumes the partner will respond, and the statutory clock keeps running.
The Clarysec joint controller evidence model
A mature joint controller arrangement should be understandable in one page and provable in ten minutes. The goal is not to bury teams in legal paperwork. The goal is to make responsibilities visible, accepted, and testable.
| Evidence object | What it proves | Clarysec toolkit location | Owner |
|---|---|---|---|
| Role determination record | Why the parties are joint controllers rather than processors or independent controllers | PIMS role determination, REG08 | Privacy Lead or Vendor Owner |
| Processing inventory entry | Purpose, PII categories, lawful basis, retention, systems, recipients, and transfers | REG02 | Privacy Lead or Legal |
| Responsibility allocation | Who handles notices, rights, breach coordination, retention, transfers, security contacts, and audit support | REG08 | Vendor or Procurement Owner |
| Public summary | How individuals are informed of the essence of the arrangement and contact point | REG07 | Privacy Lead or PIMS Manager |
| Rights workflow | Intake, validation, routing, partner support, response owner, deadlines, and evidence | REG06 or DSR register | Privacy Lead and Support |
| Breach coordination record | Lead notifier, communications owner, decision log, incident classification, and evidence | REG10 | Incident Manager and Privacy Lead |
| Contract clauses | Data sharing, liability, audit, confidentiality, security, transfers, termination, and subcontractor rules | Contract register | Legal and Procurement |
Clarysec’s privacy policies reinforce each layer.
The Privacy Notice and Transparency Policy, clause 4.1.5, states:
[Joint Controller] The Privacy Lead / PIMS Manager MUST record the public-facing joint-controller responsibility summary and contact point in REG07 before joint-controller processing is launched or materially changed.
The PII Principal Rights Management Policy, clause 6.1.5, states:
[Joint Controller] The Privacy Lead / PIMS Manager MUST document rights-handling responsibilities and contact routes in REG02, REG06 or REG08 before joint-controller processing begins.
The PII Incident and Breach Management Policy, clause 4.2.5, adds:
[Joint Controller] The Privacy Lead / PIMS Manager MUST verify the agreed breach responsibility, lead communication responsibility, and coordination arrangement before any external notification or communication by a joint controller, and MUST record the decision in REG08 and REG10.
This is the point where ISO/IEC 27701:2025 and GDPR become operational. The organization does not merely say responsibilities are allocated. It shows where they are recorded, who approved them, when they were tested, and how they are used.
Practical example: REG08 for a remote monitoring platform
Assume CareConnect and MetroHealth jointly operate a remote monitoring platform. Both decide why patient data is processed, which data is collected, how monitoring alerts are configured, how analytics are used, and how patients interact with the service.
First, REG02 should record the processing activity:
- Processing name: Remote patient monitoring service
- Controller role: Joint controller
- Parties: CareConnect and MetroHealth
- Purpose: patient monitoring, care coordination, service improvement, platform analytics
- PII categories: contact data, account identifiers, clinical observations, device events, support interactions
- Special category check: health data is processed and requires heightened safeguards
- Lawful basis: documented per party and purpose
- Retention: defined by clinical, platform, legal, and operational requirements
- Systems: mobile app, monitoring platform, support tool, analytics warehouse, identity provider
- Recipients: joint controller parties, hosting provider, support vendors, notification providers
- Transfers: remote access and non-EEA processing assessed
- REG08 reference: JC-2026-004
Second, REG08 should allocate responsibility in a way that operators can follow.
| Responsibility area | CareConnect | MetroHealth | Evidence |
|---|---|---|---|
| Privacy notice drafting | Provides technical processing details | Leads patient-facing wording and publication | REG07 notice record |
| Lawful basis record | Documents platform analytics basis | Documents care delivery and patient relationship basis | REG02 lawful basis entry |
| Data subject access requests | Provides platform data exports within agreed SLA | Leads intake, validation, identity checks, and response | REG06 workflow |
| Rectification and deletion requests | Executes approved changes in platform systems | Determines clinical record handling and patient communication | DSR evidence log |
| Breach assessment | Detects, contains, and classifies platform incidents | Assesses patient impact and regulatory communication | REG10 breach record |
| External notification | Leads for platform-originated incidents where agreed | Leads patient and authority contact where agreed | REG08 and incident playbook |
| Security safeguards | Maintains platform controls, logging, access, and cloud security | Maintains hospital-side access and operational controls | SoA and control evidence |
| Processor management | Manages cloud and SaaS subprocessors | Manages hospital processors and downstream recipients | Supplier register |
| Retention and deletion | Deletes or anonymizes platform records per schedule | Confirms clinical retention and downstream deletion rules | Retention register |
| Audit evidence | Provides logs, policies, test results, and attestations | Provides governance approvals and rights records | Audit request tracker |
Third, REG07 should record the public-facing summary. The notice should explain the essence of the joint arrangement in plain language, identify the joint controllers, describe what each is responsible for, and provide a usable contact point. It should not force patients or users to decode internal operating complexity.
Fourth, test the workflow before launch. Send a simulated access request to the published contact point. Confirm that Support identifies it as a PII principal rights request, routes it to Privacy, checks REG08, requests partner input, records actions in REG06, and produces a response pack. Then run a breach tabletop using a scenario such as “API endpoint exposes patient identifiers to unauthorized users” or “deletion-suppressed users are accidentally included in an engagement campaign.”
These tests expose the real gaps: unowned mailboxes, unclear partner SLAs, unapproved notice text, incomplete lawful basis records, missing special-category checks, and incident playbooks that do not name the external communication lead.
Map Article 26 to ISO/IEC 27002:2022 controls through Zenith Controls
A joint controller arrangement is not only a legal artifact. It must be supported by technical and organizational controls. Zenith Controls helps teams map ISO/IEC 27001:2022 and ISO/IEC 27002:2022 control expectations to privacy, supplier, incident, cloud, and governance evidence.
Three ISO/IEC 27002:2022 controls are especially relevant.
Control 5.2, Information Security Roles and Responsibilities, supports the operating model. It connects to ISO/IEC 27001:2022 Clause 5.3, Organizational roles, responsibilities and authorities. It also supports incident readiness because unclear roles undermine ISO/IEC 27002:2022 Control 5.24, Information Security Incident Management Planning and Preparation. In joint controller governance, Control 5.2 is where the RACI, REG08 owners, DSR handlers, breach leads, and escalation contacts become audit evidence.
Control 5.31, Legal, Statutory, Regulatory and Contractual Requirements, is where GDPR Article 26 becomes part of the ISMS rather than a Legal-only issue. It supports identification and management of GDPR Article 5 accountability, Article 6 lawful basis, Article 26 responsibility allocation, Article 32 security, Article 33 supervisory authority notification, and Article 34 communication to affected individuals. It also connects to ISO/IEC 27001:2022 Clause 4.2, understanding the needs and expectations of interested parties, and Clause 6.1.3, information security risk treatment.
Control 5.34, Privacy and Protection of PII, brings PII protection into the security operating model. It is especially important where the arrangement uses cloud analytics, shared dashboards, data clean rooms, monitoring platforms, marketing automation, or support tooling. Related safeguards may include ISO/IEC 27002:2022 Control 5.23, Information Security for Use of Cloud Services, and Control 8.11, Data Masking.
The supporting ISO ecosystem matters as well. ISO/IEC 27018 helps where public cloud services process PII. ISO/IEC 29100 provides privacy principles such as transparency, consent, legitimate purpose, collection limitation, data minimization, use limitation, accuracy, security safeguards, and accountability. ISO/IEC 27001:2022 provides the management-system backbone through context, interested parties, scope, leadership, risk assessment, risk treatment, Statement of Applicability, internal audit, management review, and continual improvement.
Contracts must match the operating model
A joint controller arrangement cannot live only in a privacy notice. It must be reflected in contracts, schedules, operating procedures, incident playbooks, escalation routes, and termination provisions.
Clarysec’s Legal and Regulatory Compliance Policy, clause 5.3.1.2, explicitly brings contract types into governance, including:
Contracts involving data sharing, intellectual property rights, liability limitations, or audit clauses
The Data Protection and Privacy Policy, clause 5.1, sets the enterprise foundation:
The organization shall maintain a formal Privacy Governance Framework integrated into the Information Security Management System (ISMS) to enforce this policy.
For SMEs, the same principle is scaled to operational reality. The Data Protection and Privacy Policy-sme - SME, clause 5.2.1, states:
The Privacy Coordinator must maintain a register of all personal data processing activities, including data categories, purpose, lawful basis, and retention periods
Clause 5.2.2 adds:
Contracts with third parties handling personal data must include data protection clauses and must be reviewed by the GM or legal adviser
This is proportional governance. A multinational may have separate legal, privacy, procurement, security, risk, and compliance teams. An SME may rely on a Privacy Coordinator, General Manager, and external legal adviser. The evidence expectation remains the same: processing activities, responsibilities, lawful basis, notices, rights handling, incident escalation, and termination duties must be documented and reviewable.
The Zenith Blueprint, Step 23, Organizational controls, supports supplier agreement discipline through confidentiality, access control responsibilities, technical and organizational measures, incident reporting timelines, audit rights, subcontractor controls, and end-of-contract provisions. In joint controller relationships, those clauses should be adapted to data sharing and responsibility allocation rather than copied from a processor template.
Incident and breach governance: decide the lead before the breach
Joint controller breaches become chaotic when teams wait until the incident to decide who communicates externally.
GDPR defines a personal data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. Where required, supervisory authority notification must occur without undue delay and, where feasible, within 72 hours after becoming aware of the breach. NIS2 and DORA can add additional cyber incident reporting and client communication expectations.
Clarysec’s Incident Response Policy-sme - SME, clause 5.3.2, captures the timing discipline:
Response timelines, including data recovery and notification obligations, must be documented and aligned with legal requirements, such as the GDPR 72-hour personal data breach notification requirement.
The Zenith Blueprint, Step 5, Communication, Awareness, and Competence, emphasizes external communication planning, including customers, regulators, partners, and the public. For joint controllers, the incident matrix should identify who performs initial breach classification, who contacts the other controller, who determines whether PII is affected, who assesses notification thresholds, who drafts authority notifications, who communicates with individuals, who coordinates NIS2 or DORA reporting, who approves public statements, and who records evidence in REG10.
If the arrangement involves a financial entity under DORA, the incident process should also support major ICT-related incident classification, escalation to senior management, intermediate updates, final reporting, and client communication where financial interests are affected. If the organization is in scope for NIS2, significant incident reporting may require staged notification and service recipient communication.
The safest practice is a joint tabletop before launch. A good scenario forces teams to use REG08, REG10, the incident playbook, partner contacts, notification templates, escalation trees, and evidence logs under time pressure.
Cross-compliance: Article 26 rarely lives alone
Joint controller arrangements often sit inside broader regulated ecosystems. A fintech campaign, connected health platform, managed service relationship, cloud marketplace integration, or digital infrastructure partnership may trigger obligations beyond GDPR.
NIS2 can apply to medium and large essential or important entities in sectors such as digital infrastructure, cloud computing, data centers, managed service providers, managed security service providers, online marketplaces, search engines, and social networking platforms. NIS2 Article 20 places cybersecurity risk-management oversight on management bodies. Article 21 requires technical, operational, and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, secure development, vulnerability handling, training, encryption, HR security, access control, asset management, and authentication. Article 23 introduces staged reporting for significant incidents.
DORA applies from 17 January 2025 to many financial entities. It covers ICT risk management, major ICT-related incident reporting, digital operational resilience testing, ICT third-party risk, contractual arrangements with ICT providers, and oversight of critical ICT third-party service providers. DORA Article 5 places ICT risk governance at management-body level. Articles 8 to 14 cover asset identification, protection, detection, continuity, backup, recovery, lessons learned, training, and crisis communications. Articles 17 to 20 define incident lifecycle and reporting. Articles 28 to 30 make third-party ICT risk, contract terms, registers, concentration risk, audit rights, and exit planning central obligations.
NIST CSF 2.0 provides a practical integration layer. Its GOVERN Function includes legal, regulatory, contractual, privacy, and civil liberties obligations, leadership accountability, risk appetite, policy, oversight, and supplier risk. Outcomes such as GV.OC-03 and GV.SC-02 align naturally with Article 26 evidence because they require legal obligations and partner roles to be understood, managed, communicated, and coordinated.
| Compliance lens | What it asks in a joint controller arrangement | Clarysec evidence |
|---|---|---|
| GDPR | Who determines purposes and means, how responsibilities are allocated, how individuals are informed, and how rights and breaches are handled | REG02, REG07, REG08, REG10, DSR logs |
| ISO/IEC 27701:2025 PIMS | Whether privacy roles, processing records, lawful basis, transparency, rights workflows, incident handling, and accountability evidence are managed systematically | PIMS policies, registers, management review evidence |
| ISO/IEC 27001:2022 | Whether legal requirements, privacy obligations, supplier dependencies, cloud use, incident roles, and risk treatment are inside the ISMS | Scope, interested-party register, risk register, SoA, Annex A evidence |
| NIS2 | Whether governance, incident handling, supply chain, access control, continuity, training, and reporting are integrated | Incident plan, supplier register, training records, continuity tests |
| DORA | Whether ICT third-party risk, incident reporting, resilience testing, data protection, and contractual controls are governed for financial services | ICT register, contract clauses, incident classification, exit plans |
| NIST CSF 2.0 | Whether current and target governance outcomes, supplier risk, incident response, and recovery are defined and measurable | CSF profile, gap plan, POA&M, risk register |
| COBIT 2019 | Whether governance objectives, accountability, performance measurement, and assurance evidence are traceable to enterprise goals | RACI, control metrics, management reporting, audit evidence pack |
The advantage of Clarysec’s model is evidence reuse. REG08 is not only a GDPR record. It supports ISO/IEC 27701:2025 accountability, ISO/IEC 27001:2022 governance, NIST CSF 2.0 supplier-role clarity, DORA third-party governance where financial services are involved, and NIS2 management oversight where the entity is in scope.
What auditors and regulators will test
Different reviewers will approach joint controller governance through different lenses, but they will converge on the same core question: can the organization prove accountability works?
| Auditor lens | Likely audit question | Evidence that should be ready |
|---|---|---|
| ISO/IEC 27001:2022 auditor | Are legal, regulatory, contractual, privacy, supplier, incident, and cloud requirements identified and included in ISMS scope and risk treatment? | Scope, interested-party register, compliance obligations register, risk assessment, SoA, supplier controls |
| ISO/IEC 27701:2025 PIMS auditor | Are PIMS roles determined, and are joint controller responsibilities documented before processing begins? | REG02, REG07, REG08, rights workflow, breach records, management review |
| GDPR-focused auditor or DPO reviewer | Can the organization demonstrate Article 5 accountability and Article 26 responsibility allocation? | Joint controller arrangement, notice summary, lawful basis records, DSR logs, breach decision logs |
| NIST CSF 2.0 assessor | Are privacy, legal, supplier, incident, and recovery outcomes represented in Current and Target Profiles with a remediation plan? | CSF profile, gap analysis, risk register, POA&M, supplier monitoring |
| DORA reviewer | Are ICT third-party dependencies, incident reporting, resilience, contractual rights, and exit plans governed where financial services are involved? | ICT contract register, incident classification, resilience tests, audit rights, exit strategy |
| NIS2 supervisor | Has management approved and overseen risk measures, supplier security, incident handling, continuity, access controls, and training? | Board minutes, policies, incident plan, continuity tests, training records, supplier risk reviews |
| COBIT 2019 or ISACA auditor | Is accountability assigned, monitored, measured, and reported through governance structures? | RACI, KPIs, control testing, management reporting, issue remediation |
The strongest audit posture is traceability. Start with the legal requirement, connect it to the PIMS policy, point to the register entry, show the workflow, then show test evidence or a real case record.
For example, GDPR Article 26 requires allocation of joint controller responsibilities. The Privacy Information Management System Policy requires REG08 before processing begins. REG08 shows responsibility allocation for notices, rights, breach, retention, supplier management, and contacts. REG07 shows the public-facing summary. A DSR simulation proves the workflow operates. Management review minutes show exceptions, decisions, and improvements.
That is auditable governance.
Management review turns privacy risk into executive accountability
Joint controller governance should not be hidden in a privacy folder. It belongs in management review because it affects regulatory exposure, customer trust, patient trust, incident readiness, supplier risk, contractual liability, and operational resilience.
ISO/IEC 27001:2022 requires leadership commitment, roles, resources, policy alignment, risk-based planning, performance evaluation, and continual improvement. NIS2 places cybersecurity oversight obligations on management bodies. DORA places ultimate ICT risk responsibility on the management body for financial entities.
Clarysec’s Governance Roles and Responsibilities Policy-sme - SME, clause 5.5, states:
All significant security decisions, exceptions, and escalations must be recorded and traceable.
For enterprise organizations, the Governance Roles and Responsibilities Policy, clause 5.2, requires:
A Roles and Responsibilities Register shall be maintained and shall include:
That register should include privacy governance roles where they affect security, incident response, supplier assurance, operational resilience, and executive reporting. Joint controller exceptions should be escalated before launch, not discovered after a complaint.
A practical management review pack should include:
- New and changed joint controller arrangements
- REG08 completion status
- High-risk processing activities and DPIA status where applicable
- Open lawful basis or transparency issues
- DSR performance and overdue partner actions
- Breach tabletop results and unresolved gaps
- Supplier, subprocessors, cloud, and transfer dependencies
- Retention and termination exceptions
- Audit findings and remediation status
- GDPR, NIS2, DORA, NIST CSF 2.0, and COBIT 2019 reporting impact
A five-step Clarysec approach to make Article 26 auditable
If your organization shares decision-making over PII processing with another party, do not wait for a complaint, audit, breach, or partner dispute to clarify responsibilities.
Use this five-step approach:
- Use Zenith Blueprint Step 2 to identify stakeholders, legal requirements, partner expectations, privacy obligations, and regulatory scope.
- Use Zenith Blueprint Step 4 to build a RACI for notices, lawful basis, rights, breach communication, retention, transfers, suppliers, audit evidence, and termination.
- Record the processing activity in REG02 and the joint controller responsibility allocation in REG08 using Clarysec’s PIMS policy set.
- Map the arrangement through Zenith Controls, especially ISO/IEC 27002:2022 Control 5.2, Control 5.31, and Control 5.34.
- Test the arrangement with a DSR simulation and breach tabletop before processing begins.
CareConnect and MetroHealth did not need more informal alignment. They needed a documented responsibility allocation, a public-facing summary, a rights workflow, a breach coordination record, contractual clauses, and management review evidence.
That is the difference between “we thought the partner handled it” and “here is the approved arrangement, notice, workflow, test evidence, and breach decision record.”
Clarysec can help you implement ISO/IEC 27701:2025 PIMS governance, align it with GDPR Article 26, integrate it into your ISO/IEC 27001:2022 ISMS, and produce audit-ready evidence across GDPR, NIS2, DORA, NIST CSF 2.0, and COBIT 2019 expectations.
Ready to replace joint controller ambiguity with audit-ready evidence? Explore the Zenith Blueprint: An Auditor’s 30-Step Roadmap, use Zenith Controls: The Cross-Compliance Guide, or contact Clarysec for a PIMS and ISMS assessment that turns Article 26 into an operating control system before your next partnership goes live.
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council