What to Check Before Moving an ISO Workflow to a Third-Party Cloud

01Classify the workflow and its information

Inventory records, personal data, trade secrets, customer specifications and regulatory evidence that will enter the service. Determine who uses the workflow and which decisions depend on it. A public training calendar carries different exposure from confidential incident findings, restricted worker health information or the sole authoritative record of product release.

Assess business impact of service outage, data alteration, confidentiality breach or loss of audit history. For each record type map retention and preservation obligations, relevant jurisdictions, customer terms and the expected retrieval form. This assessment determines the cloud control requirements and whether the provider can realistically meet them.

Include metadata, attachments and linked records in the scope. Exporting a simple CSV may be insufficient if the management-system evidence depends on versioned approvals and relationships among CAPA, training and controlled documents.

Technical context: ISO/IEC 27001:2022 — Information security management systems is one verified source for the concepts discussed here.

02Understand customer and provider responsibilities

Identify who operates identity management, encryption configuration, backups, vulnerability remediation, audit logging, change approval and data deletion. A provider may secure the infrastructure while the customer remains responsible for incorrect sharing permissions and unauthorized user accounts. The label secure cloud does not resolve these boundaries.

Use contract terms and technical documentation to map responsibilities for each control, escalation and evidence source. ISO/IEC 27001:2022 provides the management-system requirements context; ISO/IEC 27017:2026 gives cloud-control guidance for providers and customers. Neither should be misrepresented as a universal guarantee of security.

Check whether subcontractors can process the data and what changes require notification or consent. An apparently regional provider may rely on identity, storage or support services elsewhere.

Conduct the records exit demonstration during supplier evaluation, not just after several years of dependence. A vendor that cannot show an interpretable approval history now is unlikely to become more transparent once contractual leverage has diminished.

For security assurance, inspect the precise service scope and period of any reported certification or third-party audit. A generic badge on a supplier site cannot establish correct authorization for the customer’s configured business roles.

03Evaluate access and identity controls

Test single sign-on, multifactor authentication as appropriate, role-based permission, least privilege, temporary access and timely offboarding. Ensure the system can prevent a site employee from reading confidential audit evidence belonging to another legal entity without authorization.

Confirm privileged support access is controlled, logged and appropriate to the contract. Ask how administrative changes are audited and whether the customer can retrieve meaningful activity records for investigation. Verify whether the system supports segregation between creating an action, approving its closure and reviewing effectiveness.

Design tests for account compromise, mistaken sharing and compromised integration tokens. Access diagrams and certifications are useful inputs, but must be tied to the organization’s actual configuration.

Contractual availability language should be translated into the organization’s own recovery arrangements. A platform that meets a monthly uptime commitment may still experience an outage during a critical product release. Decide what work must continue, which approvals may pause and what fallback evidence is acceptable.

04Confirm data integrity, retention and retrieval

Require preservation of original inspection or approval context, timestamps, attachments, version history and decision trails. Identify whether the vendor can alter or purge records during ordinary support, and how the customer will detect inappropriate changes. Check restore processes with a representative dataset.

Review retention, legal hold, deletion, encryption-key control and data residency against actual applicable obligations. ISO/IEC 27018:2025 is relevant guidance where the provider acts as a public-cloud processor of personally identifiable information; its relevance depends on the specific processing arrangement.

Do not assume a screen view is sufficient evidence. Test readable exports, record identifiers, link integrity and records that survive a user’s departure or the end of a contract.

A provider transition should be treated as a controlled records migration. Sample both newly created and historical records, including unusual approvals, corrected entries, deleted accounts and closed actions. The objective is to confirm that the new cloud interface has not simplified away information needed to reconstruct what an auditor or regulator may later question. Use the same criterion when evaluating future upgrades.

05Examine resilience, incident communication and assurance

Ask for defined service levels, backup arrangements, recovery objectives, breach notification routes, business-continuity measures and evidence of testing. A vendor statement of high availability does not tell the organization how it will perform critical approval decisions during an outage.

Check the provider’s independent assurance reports and certifications for their actual scope, dates and exclusions. A corporate certificate may not cover the proposed application, data center, subcontracted service or customer configuration. Request enough relevant evidence to evaluate the specific workflow rather than accepting a logo.

Agree who preserves incident evidence, who communicates with customers or regulators when legally required, and how urgent service restoration is coordinated with containment and investigation.

06Set viable migration and exit terms

Before signing, negotiate export formats, reasonable extraction time, support assistance, deletion confirmation and restrictions on surprise price or API changes where possible. Exit is not only a financial negotiation; the organization must retain access to controlled records and be able to continue critical work.

Pilot a real export containing attachments, approvals, versioned documents and audit logs. Confirm that another system or secure archive can interpret relationships among records. Test a restore or read-only continuity option before making the cloud database the sole authoritative source.

Consider the effort and cost of maintaining integrations and administering role access after go-live. A low initial license price can mask expensive data cleansing, custom exports and prolonged dependence on proprietary workflows.

The security responsibility matrix needs operational owners on both sides of the service. Ask who revokes an employee account, investigates an unusual download, restores a corrupted record and approves a provider support session. A shared-responsibility diagram without named action routes has limited assurance value.

Review contractual access during disputes as well as normal service. If an invoice issue, suspension or insolvency could interrupt record retrieval, document the service and exit rights before cutover. Critical evidence should not be accessible solely through a billing-dependent portal where the organization has no tested independent archive or continuity method.

07Approve the service through operational evidence

Run a documented risk assessment with quality, information security, legal/procurement and process owners. Accept residual risks through the proper authority; do not allow IT purchasing alone to approve legal and operational exposure. Specify which controls are customer-configured and who will verify their performance.

Monitor provider changes, access exceptions, actual recoverability, incident handling, export capability and service performance after migration. Review critical workflows after software updates and contract changes. Integrate provider issues into supplier oversight and management review rather than treating cloud procurement as a completed project.

The sound cloud decision is the one the organization can operate, audit, recover and exit. The service must preserve control intent even when infrastructure and software maintenance are performed elsewhere.

Data location and subprocessor arrangements may affect contractual and privacy duties. Capture actual processing and support routes rather than relying exclusively on the marketing region shown during purchase.

An incident rehearsal should include retrieval of critical ISO evidence while the vendor portal is unavailable. If no practical path exists, the risk belongs in the migration approval decision and continuity design.

Only authorize cloud cutover after a credible export, restore and authorization test. The strongest vendor claims are insufficient if the organization cannot reconstruct its own controlled records and operational decisions.

Closing Perspective

Moving an ISO workflow to cloud transfers operational tasks, not responsibility for the integrity, confidentiality and availability of management-system evidence.