Control of data restoration

ISO/IEC 27018 Annex A.11.3 requires you to run PII data restorations through documented procedures and keep a restoration log that records each restoration effort and every individual involved. To operationalize it, standardize restoration workflows (request, approval, execution, validation, closure) and implement tamper-evident logging tied to identity, tickets, and the specific PII datasets restored.

Key takeaways:

• You need two things: documented restoration procedures and a restoration log that captures actions and people involved.
• Scope is PII restorations in public cloud environments where you act as a PII processor (including your operators and relevant third parties).
• Auditors look for end-to-end traceability: ticket → approval → restore → validation → log records → access evidence.

“Control of data restoration” is a narrow requirement with high audit visibility because restoration is a privileged, high-impact action: it can reintroduce deleted data, expose historical PII, or bypass normal change controls during incidents. ISO/IEC 27018:2019 Annex A.11.3 focuses on operational discipline: you must have restoration procedures and you must log restoration efforts and the people who performed them. ¹

For a CCO or GRC lead, the fastest path is to treat restoration like an exception-controlled production change with privacy-specific guardrails. That means: defined triggers (incident recovery, customer request, testing), role-based permissions, approvals, step-by-step runbooks, and evidence that ties actions back to named individuals and an authorized business purpose. You are building defensibility: if asked “who restored what PII, when, why, and how do you know it was correct,” you should answer from records, not recollection.

This page gives requirement-level guidance you can assign to IT, Security, SRE/DevOps, and any third party operators, then verify through evidence.

Regulatory text

ISO/IEC 27018:2019 Annex A.11.3 (excerpt): “Procedures shall be in place and a log shall be maintained to record data restoration efforts and any individual involved in restoring PII.” ¹

What the operator must do

1. Create and maintain documented procedures for restoring PII (including who can do it, how it is approved, and how it is verified).
2. Maintain a restoration log that records:
   • Each restoration effort (what happened, when, and what data was involved), and
   • Every individual involved in restoring PII (not just the person who clicked “restore,” but approvers and operators where they meaningfully participate).

This is an accountability control. If restoration can occur without identity attribution and a repeatable process, you do not meet the requirement.

Plain-English interpretation

You must be able to prove that PII restoration is controlled, repeatable, and attributable to specific people. A “restore” includes restoring from backups, snapshots, replication copies, object versioning, database point-in-time recovery, or any workflow that brings back previously deleted or unavailable PII into an environment.

A compliant program produces a clean chain of evidence:

• A restoration request exists and is legitimate.
• The restore followed an approved procedure.
• Only authorized personnel performed the work.
• Actions were logged with identities.
• Post-restore checks confirm the outcome and reduce privacy risk (wrong tenant, wrong dataset, over-restoration).

Who it applies to (entity and operational context)

Entity scope

• Cloud Service Providers acting as PII processors. ¹

Operational scope (what systems and teams)

Apply this control anywhere PII could be restored, including:

• Production systems and supporting platforms (databases, object stores, file services).
• Backup platforms and disaster recovery environments.
• Engineering/SRE/DevOps “break-glass” operations.
• Managed services or third party operators who can run restorations on your behalf.

If a third party can restore your customers’ PII (for example, a managed backup provider), your procedures must define how they request/approve/execute, and your logs must still capture individuals involved.

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

Step 1: Define “PII restoration” and scope it to concrete restore mechanisms

Create a short scope note that lists restoration methods in your environment, such as:

• Database point-in-time restore
• Snapshot rollback
• Object version restore
• Backup job restore to original location
• Restore to alternate location for investigation or eDiscovery-like needs

Operational tip: auditors will test ambiguous cases (“Is restoring a single object version a ‘restoration’?”). Your definition should answer that.

Step 2: Publish a restoration procedure (runbook) with required gates

Your procedure should be a runbook that operators can execute under time pressure. Minimum required elements:

• Trigger types: incident recovery, customer request, internal error correction, testing (if allowed), legal hold considerations (if applicable).
• Approval rules: who approves what. Common pattern:
  • Customer-requested restore requires customer authorization and internal approval.
  • Incident restore requires incident commander approval.
  • Non-emergency restores require change approval.
• Data scoping: specify tenant/account, dataset, date/time range, and restore destination.
• Access control: named roles permitted to restore; break-glass rules for emergencies.
• Verification: post-restore checks (integrity, correct tenant, correct environment, least data restored).
• Closure: document results, notify stakeholders, and attach logs.

Make the runbook explicit about privacy failure modes: restoring the wrong tenant’s data and restoring more historical PII than needed.

Step 3: Implement restoration logging that captures “effort” and “individual involved”

A restoration log can be a dedicated log, a ticketing system record, or a correlated set of records. What matters is that you can produce an audit-ready record.

Minimum fields to capture per restoration effort:

• Unique restore ID (ticket number or change/incident ID)
• Date/time started and completed
• System(s) and environment(s) (prod, DR, staging if applicable)
• PII dataset identifier (service name, database, bucket/container, table family)
• Restore type (snapshot, point-in-time, file/object restore)
• Restore source and destination (where restored from/to)
• Reason/trigger and authorizing party
• Outcome (success/partial/failure) and validation performed
• Links/attachments to machine logs (job IDs, console logs, command output)

Individuals involved (identity attribution):

• Requestor identity
• Approver identity
• Executor/operator identity
• Secondary operator/reviewer identity (if used)
• Third party personnel identity (if a third party participates)

Identity should be resolvable to a person, not a shared account. If shared accounts exist for legacy reasons, define compensating controls and a retirement plan.

Step 4: Tie restorations to access governance (RBAC + break-glass)

Update IAM so that restoration actions require:

• Specific roles with least privilege (restore rights are not “read-only”).
• Separation of duties where feasible (approval separate from execution).
• Break-glass use that is logged and reviewed.

Your restoration log should correlate to IAM evidence: “this individual had the role at the time” and “this was the credential used.”

Step 5: Operationalize with tickets, templates, and review

Make compliance the default path:

• Create a restoration request template with required fields (dataset, tenant, time range, reason, approval).
• Require ticket linkage in automation (restore job won’t run unless a ticket ID is provided).
• Perform periodic reviews of restoration logs for completeness and unusual patterns (for example, repeated restores for the same dataset or restores outside incident windows).

If you use Daydream to manage third-party risk and operational compliance evidence, map restorations to a single control record and collect artifacts (runbooks, sample logs, approvals) on a schedule. That reduces scramble during audits and makes third party operator participation easier to evidence.

Required evidence and artifacts to retain

Keep evidence that proves both “procedures exist” and “logging happens and identifies people.”

Procedure artifacts

• Data restoration policy/standard (short, control-focused)
• Restoration runbooks per platform (database, object store, backup system)
• RACI for restore roles (request, approve, execute, validate)
• IAM role definitions for restoration permissions

Operational records

• Restoration log exports or queries showing multiple real restore events
• Tickets/changes/incidents linked to each restoration
• Approvals (recorded in ticketing system or change tool)
• Machine-level logs: backup job IDs, snapshot IDs, audit logs from cloud provider consoles
• Post-restore validation evidence (checks performed, sign-off)

Third party artifacts (if applicable)

• Contract or SLA clauses that require named-person logging for restoration actions (where your procurement standards allow)
• Third party operator access lists and access reviews
• Third party restoration event records mapped to your ticket IDs

Common exam/audit questions and hangups

Auditors tend to probe traceability and identity:

1. “Show me your restoration procedure.” They want a repeatable runbook, not a vague paragraph in a policy.
2. “Provide three recent examples of PII restorations with logs.” Expect follow-ups: who approved, who executed, and how you validated the result.
3. “How do you ensure every individual involved is recorded?” If you rely on shared accounts, this becomes a finding risk.
4. “Do you restore into non-production environments?” If yes, auditors may ask how you control access and whether restored PII is minimized.
5. “How do third parties perform restorations?” They will look for the same procedure and logging expectations extended to third party operations.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails A.11.3	Fix
Logging only the backup job ID, not the people	The requirement explicitly requires recording “any individual involved”	Correlate job IDs to ticket IDs and identities (request/approve/execute)
Shared admin accounts for restore operations	You cannot attribute actions to an individual	Move to named accounts; use break-glass with individual authentication and review
“Procedure” exists but is not used in incidents	Practice diverges from documentation	Embed procedure into incident playbooks and automation gates
Restores done ad hoc via console without ticket	No business purpose or approval trail	Require ticket ID for restore, block console restores where possible
Restoring more PII than needed	Expands privacy exposure and can create customer impact	Require scoping fields (tenant, time window, dataset) and restore-to-isolated location for review where feasible

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so this page does not cite specific actions. Practically, weak restoration controls raise predictable risks: unauthorized reintroduction of PII, cross-tenant data exposure, and inability to investigate incidents because you cannot prove who restored what and why. Those failures also undermine customer trust during incidents because you cannot provide a defensible timeline.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Inventory where PII restoration can occur (backup tools, snapshots, database restore functions, object versioning).
• Draft and publish a single restoration procedure with clear approval rules and role requirements.
• Implement a restoration request ticket template with mandatory fields (tenant, dataset, reason, approver).

Next 60 days (instrument and enforce)

• Implement or tighten IAM roles for restoration actions; restrict restore permissions to named roles.
• Add ticket-ID gating to restoration automation (scripts, pipelines, backup tooling integrations).
• Stand up a restoration log view that joins: ticket + IAM identity + platform audit logs.

Next 90 days (prove it and harden)

• Run a tabletop or controlled restoration test and capture end-to-end evidence.
• Perform a restoration log review and close gaps (missing approvers, incomplete dataset identifiers, ambiguous identity records).
• Extend requirements to third parties: update procedures for managed services and require identity-attributed restoration records.

Frequently Asked Questions

Does every restore require an approval, even during an incident?

The standard requires procedures and logging of restoration efforts and individuals involved. ¹ Your procedure can define expedited approvals for incidents, but you still need a recorded authorization path and identities.

What counts as “any individual involved” in restoring PII?

Include at least the requestor, approver, and the person who executed the restore, plus anyone who performed a meaningful restoration step. The requirement explicitly calls for logging “any individual involved in restoring PII.” ¹

Can we meet the requirement with cloud provider audit logs alone?

Often no, because platform logs may show the executor but not the business reason, approval, or full restoration context. Pair platform audit logs with a ticket record and a defined procedure so each restoration effort is intelligible and attributable. ¹

Do test restores (for DR testing) fall under this control?

If the test restore involves PII, treat it as in-scope because it is a “data restoration effort” involving PII. The safer operational stance is to apply the same procedure and logging, then note “test” as the reason/trigger. ¹

How should we handle third party operators who can restore PII for us?

Your procedure should define how the third party requests, gets approval, performs the restore, and provides logs that name the individuals involved. If the third party cannot provide person-level attribution, treat it as a risk exception and plan remediation. ¹

What’s the minimum we need to retain as evidence for an audit?

Retain the written procedure and sample restoration records that show the restoration effort, the PII dataset restored, and the identities of individuals involved. The requirement explicitly calls for procedures and a maintained log. ¹

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