Search every question across sub-FAQs

ISO/IEC 27018 audit evidence should let a customer identify the edition, audited entity and service, processor scope, criteria, audit date or period, sampling method, exclusions, findings, corrective-action status, report restrictions, and who performed the work. The customer then compares that scope with its own service, processing, locations, subprocessors, contract, and legal duties.

The 2019 edition recognizes independent evidence as a practical response when individual customer audits are impractical or would increase security risk in a multi-tenant cloud. It says a relevant independent audit selected by the processor should normally be acceptable only when sufficient transparency is provided. That guidance does not erase contractual audit rights or binding legal requirements.

Customers should inspect the scope statement, current report or certificate, criteria and edition, control mapping, test period, samples, qualifications or findings, corrections, subprocessor treatment, customer responsibilities, and, where the provider supplies one, any bridge letter describing the period after the report.

For higher-risk or uncovered controls, request focused operating evidence such as a subprocessor change record, breach-notice exercise, disclosure log sample, deletion result, access review, or backup-erasure procedure. Protect other customers' information and auditor-confidential material when evidence is shared.

Privacy and security owners should validate control coverage and gaps; procurement and legal should compare the evidence with customer commitments and audit rights; supplier assurance should confirm the report, certificate, issuer, and scope.

Independent evidence supports a decision but does not transfer the customer's accountability. The customer still decides whether the evidence is sufficient for its risks, contract, and applicable law.

ISO/IEC 27018 assurance evidence becomes stale when the report period ends, a certificate expires or is suspended, the cited standard edition or assurance scheme changes, the service boundary changes, a material finding remains open, or a relevant subprocessor or processing country falls outside the reviewed scope.

If a provider supplies a bridge letter, treat it as the provider's statement about changes after the report period, not as a replacement independent audit or an extension of the auditor's tested period. Record the uncovered period and obtain the next report or focused current evidence when available.

First classify the event. ISO/IEC 27018:2019 says an information security incident should trigger a review to determine whether a data breach involving PII occurred. Routine events such as port scans, unsuccessful logons, or denial-of-service attempts do not necessarily trigger that review when they create neither actual nor a significant probability of unauthorized PII access. If the breach trigger is met, notify the affected customer as the contract requires and supply the facts the customer needs for its own legal assessment and notifications.

The 2019 control does not extend its processor-to-customer notice to a breach caused by the customer or PII principal, or within components for which they are responsible. Record the service-model boundary, such as whether the customer controls application access in an IaaS or PaaS deployment, before relying on that exclusion. Other laws or contract terms may still require cooperation.

For every confirmed breach, record the incident description and period, consequences, reporter, recipients, resolution steps, person in charge, recovered data, and whether loss, disclosure, or alteration occurred. Add the compromised data if known and the steps taken to notify the customer or regulators.

The record should also preserve detection and notice times, affected service and responsibility boundary, changing facts, decision rationale, copies of notices, subprocessor input, containment and recovery evidence, and follow-up actions. Do not turn an estimate into a confirmed fact.

Incident response owns containment and the fact record; privacy and legal assess PII impact and legal duties; the service owner sends authenticated customer communications; cloud and supplier teams provide system and subprocessor facts.

The provider's customer notice is not the customer's decision about notifying a regulator or affected people. For GDPR-covered processing, the processor must notify the controller without undue delay after becoming aware of a personal data breach; the controller separately applies Articles 33 and 34.

Review after exercises and incidents and whenever services, responsibility splits, subprocessor response duties, customer contacts, notice channels, contract timing, or applicable law changes.

Test whether responders can identify the affected customer and service, reach the correct contact, assemble the 2019 edition's incident record, and meet the shortest applicable notification commitment.

Under ISO/IEC 27018:2019, instructions to a public-cloud PII processor can be contained in the contract and can include the service objective and time frame. An order, customer-controlled configuration, authenticated support request, or approved change can implement that contract when the authorized channel, requester, service, PII, operation, purpose, and duration are clear.

A processor may choose technical methods needed to deliver the customer's purpose without an express instruction for every implementation detail. For example, the provider may allocate processing resources to use network capacity efficiently. The method must remain consistent with the customer's general instructions, follow the relevant privacy principles when it collects or uses PII, and never introduce an independent processing purpose.

Keep the instruction, requester identity and authority, receipt and completion times, affected service and PII, operation, purpose and time frame, provider action, configuration or ticket evidence, approvals, exceptions, and downstream subprocessor effects.

Link the instruction to the applicable contract version and retain change history. Logs should show what the provider did without exposing another customer's information or retaining PII longer than the defined logging purpose requires.

The customer identifies authorized instructing roles. The provider's service owner validates operational scope; privacy and legal assess purpose, role, and legal conflicts; security reviews changes to access or controls; supplier management handles subprocessor effects.

Do not treat silence, an informal message from an unknown requester, or a provider's own product goal as a customer instruction. Resolve ambiguity before processing outside the established baseline.

Review for new purposes, features, data, users, locations, subprocessors, support access, retention, deletion, or provider use that could turn instructed processing into own-purpose processing.

Also review when the authorized customer roles, instruction channels, contract version, or responsibility split changes. Update the baseline before accepting new instructions.

The standard's guidance on customer instructions, confidentiality, security, subprocessors, breach support, disclosures, customer-rights support, and return or disposal can support evidence for related GDPR processor duties when the same service, processing purpose, systems, countries, and review period are in scope.

Map the sources rather than treating them as interchangeable. The GDPR is binding law where its territorial and material scope tests are met. Article 28 then creates contract and processor requirements; ISO/IEC 27018 supplies voluntary control guidance and may also become a contractual criterion.

Reuse data flows, purpose-specific role decisions, Article 28 terms, control tests, subprocessor authorization and notices, processing-country and transfer records, incident support, rights-request assistance, and deletion evidence only when the covered entity, service, systems, countries, data, purpose, and period match.

Article 28 requires processing on documented instructions, confidentiality, Article 32 security, subprocessor conditions, assistance with rights and certain controller duties, return or deletion, information demonstrating compliance, and audits. An ISO control or audit report can support that record but cannot establish every element without the contract and operating facts.

Authorized privacy or legal owners interpret GDPR applicability and roles; the DPO performs the independent tasks assigned by Articles 38 and 39 where one is designated. Security and cloud owners validate control operation, while procurement and service owners confirm provider commitments.

Do not assign the DPO operational ownership merely because a decision concerns personal data. Preserve the DPO's ability to monitor and advise without receiving instructions on those statutory tasks.