Claims Migration: Audit, Risk Ratings and Defect Severity

Analyse stakeholders on influence and interest, and on what each needs from the test evidence.

• Compliance officer: high influence, high interest, needs traceable evidence that every data-integrity defect was identified, owned and either resolved or formally accepted. Treat as a partner; agree the evidence format before the audit rather than after.
• Product owner: high influence, medium interest in test detail, high interest in release date. Needs the cost of accepting defects made explicit in business terms.
• Legacy operations manager: medium influence, currently low engagement - and the most important person for the batch interface, because they know the quirks the product owner cites. Losing them means severity judgements are made without the operational evidence behind them.
• Data protection officer: high influence on personal-data handling in the migrated records, high interest in masking and retention, low interest in test mechanics.
• Auditors and the business sponsor: high influence, need a defensible narrative and a single source of truth.

Engagement approach: do not ask the two absentees back to 'the triage meeting' - that format failed them. Give each a specific, bounded role. Ask the legacy operations manager to own the accepted-quirks register: a short list of known interface behaviours with business impact and named acceptance, reviewed weekly. Ask the data protection officer to sign off the test-data masking approach and the data-integrity defect criteria, a one-off decision rather than a recurring meeting. Both get a 15-minute monthly review slot and a written summary. People re-engage with a decision they own, not with an invitation to observe.

The disagreement is about definitions, not about facts, so fix the definition first. Run a 90-minute risk workshop with the business owners, the product owner and the test team using a shared likelihood-by-impact scale with written anchors (for example, impact anchored on regulatory penalty, customer detriment and financial loss bands, not on adjectives). Rate each of the 34 items in the room, and merge the three duplicates into one item with a single owner - duplicate risks inflate the count and dilute the debate.

The expected outcome is convergence on roughly 7-9 genuinely high risks; neither the original 12 nor the team's 5 survives unchanged. Record every rating with its rationale and who agreed it, because the audit will ask.

On coverage, apply a risk-based decision rule rather than coverage as an aspiration: every high risk must have at least one test at the appropriate level, a named owner, and an entry in the traceability record. For the nine uncovered high risks, decide each one explicitly - test it, mitigate it by other means (reconciliation scripts, staged migration, manual sampling), or accept it with a signed residual-risk statement from the business owner. What is not acceptable is leaving them unassessed, which is exactly what the auditor will find.

Timebox it: two days to re-rate, one week to close the coverage gaps, prioritised by residual risk. And report the accepted risks prominently in the audit pack - a documented acceptance is defensible; silence is not.

The conflict exists because the organisation is using one field for two different questions. Separate them.

Severity is a technical and business-impact assessment: data corrupted, records affected, recoverability, regulatory exposure. It is set by the triage group using written criteria, not by the product owner alone.

Priority is a scheduling decision: when, or whether, it is fixed. That is the product owner's call, and it is legitimate for them to say 'not this release'.

So the rule becomes: the product owner may set priority to deferred, but may not lower severity, and any data-integrity defect that is deferred requires a formal acceptance signed by the business owner and the compliance officer, with the affected record volumes and a remediation date. That satisfies compliance without pretending every quirk blocks release.

Evidence trail for the audit:

• One defect register as the single source of truth, with an immutable audit trail (the second tool without a trail must be retired or synchronised before the audit).
• Mandatory fields: who raised, when, severity with rationale, owner, status history, resolution, and acceptance signature for anything deferred.
• A data-integrity defect subset that maps directly to the compliance requirement.
• A risk-to-defect-to-test traceability report showing coverage of the high risks.
• A signed residual-risk statement listing accepted interface behaviours, referenced from the register.

Rehearse it: run an internal audit two weeks before the real one using only the documentation, with no verbal explanation allowed. Whatever cannot be evidenced from the record is a gap to close, not a story to tell.