# 7. How do we move from spreadsheets to GRC software and clean the risk register first?

Define the target records and ownership before importing the spreadsheet. KPMG’s implementation guidance explicitly separates data rationalisation, migration strategy and testing; that supports treating migration as a controlled workstream rather than a file upload. [Implementation guidance](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf). ([kpmg.com](https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2024/implement-grc-technology-right-way.pdf))

**Our proposed migration sequence:** inventory → classify → cleanse → map → trial load → reconcile → approve → cut over.

Use separate linked records where the chosen model requires them:

| Record | Suggested minimum migration fields |
|---|---|
| Risk | Source ID, description, entity, accountable owner, assessment date, methodology, current decision |
| Control | Source ID, objective, activity, frequency, owner, scope, status |
| Assessment or test | Related record ID, period, assessor, method, result, reviewer |
| Evidence | File/reference ID, related record, period, source, access classification |
| Issue or action | Related risk/control, owner, due date, status, closure rationale |

For the risk register specifically:

- Resolve duplicate identifiers before discussing semantic duplicates.
- Separate the risk description from the existing issue or remediation task.
- Record the scoring methodology behind each rating.
- Identify stale assessments and missing owners.
- Preserve local distinctions until an accountable owner approves consolidation.

**Synthetic example:** two rows called “Access review” may describe one common control objective but different operating controls for different systems. Do not merge them solely because their titles match.

Approve mappings and exceptions before requesting a fixed migration price. A sample can reveal defects; it cannot establish the condition of the entire estate.