Spike — Confirm Data Retention & Compliance Requirements for DRS

**Persona:** Product Team (BA + Records/IM)
**Value:** Make sure DRS keeps digital records for the right amount of time, following BC Government rules

## Spike Story — Data Retention for DRS
As a **product team**, I want to **understand the data retention rules for all records stored in DRS**, so that **we can confirm we’re meeting BC Government policy and FOIPPA requirements**.

## Context
This spike is only about **digital records stored in DRS** (MHR, PPR, and any other registries that use it).
- **In scope:** Digital records in DRS.
- **Out of scope:** Physical storage, boxing, or off-site holdings (those are handled elsewhere).
- Goal: give us a clear picture of which rules apply, whether we’re following them today, and what fixes or controls are needed.

## BA Instructions
Stick to WHAT (the rules, policies, and requirements). No technical HOW.

### BA — questions to answer
- What BC Government **retention schedules** (ARCS/ORCS) apply to records in DRS? How long should we keep each type (MHR, PPR, others)?
- Who is the **responsible office** (OPR) for each record type?
- What does **FOIPPA s.31** require for records in DRS? Are we meeting that today?
- Where can you find the **official policy sources** (e.g., ARCS/ORCS schedules, IM/Records guidance, OCIO policy)?
- How do records get into DRS? (scan or upload → system tags/indexes them → record shows up in DRS). Are there any **backlogs or gaps** where records get stuck or skipped?
- If there are problems, what **fixes** should we recommend (clear the backlog, fix routing, add monitoring/alerts, set up regular compliance checks)?
- What **ongoing safeguards** do we need to stay compliant (automatic retention, clear audit logs, scheduled reviews)?

### Deliverable
- BA posts findings **in this ticket**, with links to the official sources.
- Update the **user flow diagram** to show how records move through DRS and how long they stay. Paste the link here.

RACI: BA (Owner); Records/IM (Consulted); PO (Informed).
Timing: complete before any remediation work is turned into stories.

## Sprints
| Role (icon + text) | Forecasted (PO-planned) | Actual (post-planning) |
|--------------------|--------------------------------------|-------------------------|
| 🧭 PO | Sprint 26.5 (Sept 3 – Sept 17, 2025) | Sprint __ (___–___) |
| 📌 BA | Sprint 26.5 (Sept 3 – Sept 17, 2025) | Sprint __ (___–___) |
| 🎨 Design | N/A (policy-focused spike) | N/A |
| 💻 Dev | N/A (policy-focused spike) | N/A |

## Acceptance Criteria
- [ ] BA confirms which retention schedules apply and how long we keep each record type.
- [ ] BA confirms who is responsible for each record type.
- [ ] BA documents FOIPPA s.31 obligations and current compliance.
- [ ] BA maps how records move into DRS and notes any gaps/backlogs.
- [ ] BA recommends fixes where needed.
- [ ] BA lists ongoing safeguards needed (retention rules, audit logs, reviews).
- [ ] Findings are documented **in this ticket** (no separate Word docs only).

## Priority
- High

## Due Date
- 2025.09.05

## Raised On
- 2025.08.20

Start with the official ARCS/ORCS schedules, IM/Records guidance, OCIO policy, and FOIPPA s.31. Use the ticket’s questions and acceptance criteria to document retention periods, responsible offices, current compliance, gaps, fixes, and safeguards. Update the referenced user flow diagram and post findings and official links in this ticket.

Written by the indexing model from the issue text.