Information security roles and responsibilities

To meet the ISO/IEC 27018:2019 “information security roles and responsibilities” requirement, you must formally define and assign information security responsibilities, and—if you are a public cloud PII processor—designate a clear customer-facing point of contact for PII processing matters. Operationalize it by publishing a responsibility model, naming accountable owners, and keeping evidence that customers can reach the right person. ¹

Key takeaways:

• Documented role ownership must cover security and privacy responsibilities end-to-end, not just “the security team.”
• Public cloud PII processors need an explicit customer point of contact for PII processing questions and issues.
• Auditors look for allocation evidence (RACI/role descriptions), operating cadence, and proof the contact path works in practice.

If you process customer PII in a public cloud context, “roles and responsibilities” is not a generic policy exercise. ISO/IEC 27018:2019 Clause 6.1.1 expects two outcomes: (1) information security responsibilities are defined and allocated across the organization, and (2) customers have a designated point of contact about PII processing. ¹

In audits, this requirement often fails in a quiet way. Teams can show an information security policy and an org chart, but cannot show who is accountable for specific PII processing obligations (subprocessor controls, access approvals, incident communications, deletion requests, logging, and exception handling). Another common gap is a “shared mailbox” or generic support channel that is not clearly designated for PII processing, or routes requests without ownership, tracking, or response expectations.

This page gives requirement-level implementation guidance you can execute quickly: who must be named, what to write down, how to connect roles to workflows, and what artifacts to retain so an auditor can trace accountability from the ISO clause to daily operations.

Regulatory text

ISO/IEC 27018:2019 Clause 6.1.1 states: “All information security responsibilities shall be defined and allocated. The public cloud PII processor shall designate a point of contact for use by the cloud service customer regarding the processing of PII.” ¹

What the operator must do:

1. Define and allocate information security responsibilities so a reviewer can see who owns which security and privacy-related activities, decisions, approvals, and escalations.
2. Designate a customer-facing point of contact for PII processing if you act as a public cloud PII processor. This must be explicit (named role or function), accessible to customers, and tied to your PII processing obligations. ¹

Plain-English interpretation (what this means in practice)

You need a written responsibility model that answers, without debate:

• Who decides and approves security exceptions?
• Who owns the PII processing inventory and related customer commitments?
• Who approves access to production systems handling PII?
• Who coordinates incident response communications to customers when PII is involved?
• Who manages subprocessors and makes sure contractual and operational controls exist?
• Who is the customer’s “front door” for PII processing questions, complaints, and requests?

If those answers live only in people’s heads, you are not meeting the requirement. If the “point of contact” is unclear, unmonitored, or disconnected from the teams that can act, you are not meeting the requirement.

Who it applies to

Entity scope

• Cloud Service Providers acting as PII processors in a public cloud context. The explicit “point of contact” requirement applies to the public cloud PII processor. ¹

Operational context (where this gets tested)

• You provide a cloud service that processes customer PII (including support, telemetry, backups, or log data that contains PII).
• You rely on third parties (for example, subprocessors) for hosting, support tooling, analytics, or service delivery where PII could be processed.
• You need repeatable handling for customer questions about PII processing (data location, access controls, disclosures, retention/deletion, incident notifications).

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

Step 1: Define the minimum role set and decision rights

Create a short list of roles that must exist for your operating model. Keep it role-based so it survives staff changes. At minimum, define owners for:

• Information Security Management (security program governance, risk acceptance, security policy ownership)
• Privacy/PII Processing Oversight (PII processing commitments, customer PII inquiries path, subprocessor oversight coordination)
• Engineering/Operations Control Owners (identity and access management, logging/monitoring, vulnerability management, change management)
• Incident Response Lead (triage, containment, forensics coordination, customer communications coordination when PII is implicated)
• Customer PII Processing Point of Contact (designated interface for customers for PII processing matters) ¹

Define the “decision rights” for each role: approve/deny, consult, execute, or inform.

Step 2: Build a RACI that maps roles to real workflows (not just controls)

Auditors and customers will evaluate whether accountability is operational. Build a RACI against the workflows that create PII risk:

• Customer onboarding and contract/security addendum review (PII commitments)
• Subprocessor intake and changes (PII flow and controls)
• Access request and privileged access reviews for systems processing PII
• Change management for services that process PII
• Incident intake, severity assignment, and customer notification routing when PII is involved
• Data retention and deletion request handling related to PII processing
• Customer inquiries/complaints about PII processing (the point of contact flow) ¹

Keep the RACI tight: name one “Accountable” owner per workflow. Multiple accountable owners is a common failure mode.

Step 3: Designate the customer point of contact and make it real

ISO/IEC 27018 requires a designated point of contact for customers regarding PII processing. Decide what “designated” means in your org:

• A named function (for example, “Privacy Operations”) with a monitored inbound channel
• A named role (for example, “PII Processing Contact”) with delegation rules and backup coverage
• A published contact method available to customers (support portal category, email alias, or ticket form) tied to an internal case workflow ¹

Minimum operational expectations you should implement:

• Clear intake criteria: what counts as a PII processing inquiry vs. general support
• Routing rules: who receives, who investigates, who approves the response
• Tracking: every inquiry becomes a case/ticket with an owner and disposition
• Escalations: how urgent PII matters reach security/privacy leadership

Step 4: Publish the responsibility model where it will be used

Place the artifacts in the systems your teams already use:

• Security governance repository (policies/standards)
• Customer trust documentation area (if you provide one)
• Support/portal knowledge base entry that points customers to the PII processing contact ¹

Keep customer-facing content concise. Customers want a contact path and scope, not your internal org chart.

Step 5: Add operating cadence and proof of execution

Defined roles do not pass audits if they do not operate. Implement:

• A repeatable review of role assignments and RACI ownership during organizational changes
• Meeting notes or decision logs for security risk acceptance and PII processing escalations
• Evidence that the PII point of contact receives and resolves cases (ticket samples, redacted) ¹

If you run Daydream for third-party risk management and due diligence, connect subprocessors and PII-related third-party workflows to named internal owners in the same responsibility model. That closes a common gap where third-party ownership is “everyone and no one.”

Required evidence and artifacts to retain

Retain artifacts that prove both definition and allocation, plus evidence the customer contact mechanism works:

Governance artifacts

• Information security roles and responsibilities document (or policy section) with named role owners
• RACI matrix mapping roles to PII-relevant workflows
• Job descriptions or role profiles for security/privacy ownership roles (role-based, not person-based)
• Delegation/backup coverage documentation for the PII contact role/function ¹

Operational artifacts

• Evidence of customer-facing PII processing point of contact (portal page, support category, published email alias, customer documentation excerpt)
• Ticketing/case records showing intake, assignment, investigation, approvals, and closure for PII processing inquiries
• Incident records demonstrating who led customer communications for PII-related incidents (redacted)
• Change management or access approval records showing named approvers by role ¹

Common exam/audit questions and hangups

Auditors and customer assessors often ask:

• “Show me where responsibilities are defined and allocated. Where is the RACI?”
• “Who is accountable for PII processing inquiries from customers?”
• “How does a customer reach the PII processing contact?”
• “What happens when that person is out? Who is backup?”
• “Provide evidence of PII processing inquiries and how they were resolved.”
• “Where do subprocessor decisions live, and who signs off?” ¹

Hangups that slow audits:

• The RACI exists but does not map to actual workflows.
• The point of contact is generic support and cannot demonstrate privacy/PII routing.
• Accountability is assigned to teams, but no single accountable owner exists for key decisions.

Frequent implementation mistakes (and how to avoid them)

1. Org chart as “evidence.” An org chart does not define responsibilities. Fix: write responsibility statements and decision rights per role, and map them to workflows. ¹

2. No explicit customer PII contact path. “Contact Support” is not the same as a designated PII processing contact. Fix: publish a specific channel for PII processing matters and tie it to an internal case process. ¹

3. Shared accountability. Multiple “A” owners in the RACI creates gaps. Fix: choose one accountable owner per workflow, then make others responsible/consulted.

4. Roles defined but not maintained. After reorgs, responsibilities drift. Fix: make role assignment review part of your change governance for leadership or team restructures.

5. PII processing inquiries handled ad hoc. Fix: treat PII processing inquiries as a case type with required fields (customer, system, PII category, request type, disposition) and an auditable closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, weak role allocation increases the chance of missed customer commitments and inconsistent incident communications, and it makes audits longer because you cannot show accountability from requirement to execution. ISO/IEC 27018:2019 Clause 6.1.1 is also a customer trust issue: enterprise customers frequently test whether your “PII contact” can answer concrete processing questions with traceable ownership. ¹

A practical 30/60/90-day execution plan

Numeric timelines are not required by ISO/IEC 27018, but a staged rollout helps you operationalize fast. ¹

First 30 days (foundation and designation)

• Name the PII processing point of contact (role/function) and publish the customer-facing contact path.
• Draft a one-page roles and responsibilities statement for security and PII processing oversight.
• Create the first-pass RACI for core PII workflows (incident, access, subprocessor change, customer inquiries).
• Stand up a case type in your ticketing tool for “PII processing inquiries,” with owner assignment rules. ¹

Days 31–60 (operational wiring and evidence)

• Train Support, Security, and Privacy stakeholders on intake criteria and escalation paths.
• Run a tabletop test: submit a mock customer PII inquiry and verify routing, ownership, and response approvals.
• Start collecting evidence: screenshots of customer-facing contact info, sample tickets, and approval records.
• Align third-party/subprocessor workflows to named internal owners; if you use Daydream, map each third party record to an accountable internal role for PII processing oversight. ¹

Days 61–90 (hardening and audit readiness)

• Expand the RACI to cover edge workflows: exceptions, logging access, data deletion coordination, and customer complaint handling tied to PII.
• Add maintenance triggers: role changes, reorgs, and new services that process PII require RACI updates.
• Prepare an audit packet: clause-to-evidence mapping for roles allocation and point-of-contact operation.
• Validate customer documentation is current and consistent with actual routing and ownership. ¹

Frequently Asked Questions

Can the “PII processing point of contact” be a shared mailbox?

Yes, if it is explicitly designated for PII processing matters, monitored, and backed by a workflow that assigns an accountable owner and tracks closure. A mailbox with no case tracking or ownership usually fails evidence review. ¹

Do we need to name a specific person, or is a role/function enough?

A role/function is typically more durable than naming an individual, as long as you can show who currently holds the role and who covers it. The requirement is designation and usability for customers. ¹

What evidence is most persuasive to auditors?

A RACI tied to real workflows plus redacted tickets showing customer PII inquiries came in through the designated channel, were assigned to an owner, and were resolved. Pair that with the customer-facing page or support instructions that disclose the contact path. ¹

We’re a SaaS provider hosted on another cloud. Are we still a “public cloud PII processor” here?

If you act as a PII processor in a public cloud service context, you should treat the clause as applicable and implement the customer point of contact. Confirm your role (processor/subprocessor) in contracts and make your contact path consistent with those commitments. ¹

Where should the PII contact be published to customers?

Put it where customers will actually look: your trust documentation, support portal, or contractual documentation set. The audit question is whether a customer can find and use it without internal guidance. ¹

How do we keep roles and responsibilities from going stale after org changes?

Treat role allocation as a governed artifact: update it during reorgs, leadership changes, and when launching new services that process PII. Tie updates to your change governance so updates are not optional. ¹

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors