Dual Roles in a Multi-Tenant HR Platform
Meridian is a Nordic HR-SaaS vendor with 180 staff, 1,400 tenant organisations and roughly 2.3 million individuals whose records sit in the platform. It has held ISO/IEC 27001 certification for three years, scoped as "the provision of the Meridian platform and corporate IT services from Oslo and Kraków", and now wants ISO/IEC 27701 added to the same certificate. The CTO's position is that Meridian is "a processor, full stop", so the team plans to implement only the PII-processor material and has told the DPO that controller requirements are out of scope. Meanwhile the DPO's processing register covers tenant employees but omits Meridian's own 180 employees and 60,000 marketing contacts. Two enterprise customers have asked for a sub-processor list that does not exist, and one contract promises breach notification within 24 hours, a commitment nobody has ever tested. The steering group wants a draft scope and statement of applicability in three weeks.
1. Should the CTO's "processor, full stop" position be accepted? Explain how role determination drives what Meridian implements and how the PIMS scope should be drawn.
Read the worked answer
Reject it. Under ISO/IEC 27701 the role is determined per processing activity, not per company, and the standard's structure follows that split: controller guidance in Clause 7 with the controller controls in Annex A, processor guidance in Clause 8 with Annex B, and shared controls in Annex C.
Meridian's activities divide at least three ways:
- Tenant employees in the platform - processor, acting on tenant instructions.
- Meridian's own 180 staff - controller (payroll, recruitment, performance, occupational health).
- 60,000 marketing contacts - controller.
Any joint controllership, for example an analytics feature co-designed with a tenant, must also be identified and documented.
Scope consequences: the PIMS scope should sit at the same boundary as the ISMS, and either include the HR and marketing processing or explicitly exclude it with a stated rationale. A scope that silently omits controller processing while the certificate implies coverage is misleading, and an auditor will test it. The statement of applicability therefore needs both the controller and processor control sets with per-control applicability and justification, not one set chosen by a slogan. Note also that the missing sub-processor list and the untested 24-hour notification commitment are processor obligations under Annex B and under the contract itself; they stay in scope whichever side of the role debate you land on.
2. The project team proposes to reuse the existing ISMS risk register, scoring privacy risks as "reputational damage to Meridian". Assess this and describe how privacy risk should be assessed and linked to the SoA.
Read the worked answer
The reuse of an existing process is fine; the reuse of the existing criteria is not. The ISO/IEC 27001 risk process scores harm to Meridian's assets and operations. ISO/IEC 27701 requires a PII protection risk assessment that also considers the likelihood and severity of harm to PII principals - discrimination, identity theft, financial loss, distress, loss of confidentiality over sensitive attributes, or being denied a service.
A workable approach:
- Inventory processing activities (not IT assets) as the unit of assessment: onboarding, payroll, platform hosting, support access, marketing, analytics, vendor transfers.
- Define two impact dimensions and combine them: impact on individuals and impact on Meridian, with explicit scales and a documented risk-appetite threshold. "Reputation" alone understates harm to data subjects and hides risks the organisation would otherwise accept too cheaply.
- Assess likelihood using realistic threat and exposure factors: volume, sensitivity, number of recipients, cross-border transfers, retention period, degree of automation.
- Record treatment decisions, owners, residual risk and re-assessment triggers (new vendor, new purpose, new law).
The SoA must then be traceable: each included Annex control should answer a risk or a legal obligation, and each exclusion should state why the risk is absent or treated otherwise. An auditor follows the thread from risk assessment to control to evidence; a register that never mentions individuals breaks that thread at the first step.
3. The DPO wants to mark the Annex A consent controls "not applicable" because tenant contracts state that tenants obtain consent. Is that defensible?
Read the worked answer
Only for part of the scope, and only if the analysis is per control and per role rather than a blanket statement.
Reasoning: for tenant-employee data where Meridian sets no purposes and takes no independent decisions, the consent controls attach to the tenant as controller; Meridian's obligations are processor ones - support the controller, keep records, not use the data for its own purposes. That exclusion is arguable and should cite the contracts and the processing register. But it is indefensible for Meridian's own marketing to 60,000 contacts, where Meridian chooses the purpose and must identify its lawful basis, determine when consent is the appropriate basis, and keep evidence of consent and withdrawal. Blanket exclusion across the whole scope would be raised as a nonconformity.
What the team should do:
- Split the applicability statement by role and by processing activity, not by control alone.
- Cite evidence: contract clauses, register entries, the marketing consent configuration and receipts.
- Record who approved each exclusion and when it will be revisited.
- Remember that even as a processor, Meridian must be able to assist controllers who rely on consent, so some capability still has to exist.
A one-line "not applicable" with no reasoning is the weakest possible answer in front of a certification auditor.