Moving the work · Lesson 7 of 10

  1. Lesson 1
  2. Lesson 2
  3. Lesson 3
  4. Lesson 4
  5. Lesson 5
  6. Lesson 6
  7. Lesson 7
  8. Lesson 8
  9. Lesson 9
  10. Lesson 10

Moving policies and evidence to a new SOC 2 platform

Short answer

Export everything for the current and last report period before your access ends: evidence, test history, policy versions with approvals, access reviews and risk records. Re-import what the new platform accepts and keep the rest in a dated archive your auditor can read.

2 min read

What should you export before you leave?

  • Evidence for the current period and the last completed period, with the dates it was collected.
  • Control test results and any exceptions with their remediation notes.
  • Every policy version, with approval dates and approvers.
  • Access reviews, onboarding and offboarding records, and training completion.
  • Your risk register and vendor risk assessments.
  • Trust center content and any questionnaire answers you reuse.

How do you keep policy history intact?

A policy that was approved last year still needs to show that approval, even if you re-approve it in the new platform. Export each version as a document with its approval record, and when you import, record the original approval date alongside the new one. Do not re-date old approvals.

What should you rebuild rather than copy?

Automated tests and integrations rarely move cleanly between platforms, because each platform defines them differently. Rebuild those in the new platform and run them before the old platform is switched off, so you have overlapping evidence. Policies, by contrast, usually move well, because they are documents.

Use the move to remove what you no longer use: duplicate policies, controls mapped to frameworks you have dropped, and evidence requests nobody answers.

Where should the archive live?

Somewhere you control, with read access for your auditor, organised by period and control. Name files with the control reference and the collection date. Keep it for as long as your contracts or regulators require.

What does the new vendor need from you?

A list of your controls and frameworks, your current policies, your integration list and your audit dates. Ask each vendor in writing what it will import and in which format. Vendor migration tooling is not described on the public pages we read, so the answer has to come from the vendor.

How do you check the import?

Pick a sample of controls and trace each one end to end: the policy that governs it, the evidence for the last period and the test results. Check that dates, approvers and file names survived the move. A sample of ten to twenty controls usually shows whether the import worked or whether something systematic went wrong, such as dates reset to the import day.