In the last unit you coordinated with security partners about who can touch data and how to keep it safe. Now the question moves further down the timeline: how long should we keep this data at all, and what happens when we're done with it? "Delete it to save space" and "keep everything just in case" are both gut reactions, and both can hurt you. Your job here is the same triage habit you've been practicing: gather context, weigh the needs, and write a clear recommendation, escalating when the stakes are high.

Before you can decide how long to keep something, you need to know where it sits in its life. The Data Lifecycle describes the stages every dataset passes through: it's created or collected, stored, used or shared, archived, retained, and eventually disposed of. Think of it like a paper file. You open it, you work from it daily, you move it to a back drawer when the project ends, you hold it in storage for a set period, and at some point you shred it.

Why does the stage matter? Because handling expectations shift as data moves along. Data in active use needs to be easy to reach and current. Once it's archived, almost nobody touches it day to day, but it isn't gone: it's being held for a reason. The retention stage is where you've decided to keep it for a defined window, and disposal is the deliberate end. Naming the stage is your first move, because "let's delete the old tickets" usually means data that has left active use and drifted into archive without anyone ever deciding how long it should stay or when it should go.

Here's the trap: retention questions arrive disguised as simple cleanup. Someone wants the clutter gone, so "just delete it" feels obvious. Resist that, and resist its opposite ("keep it forever, to be safe") too. Before proposing anything, weigh four needs. The first is business need: do teams still genuinely reference this data? The second is legal need: is there any obligation to retain it for a set period, or, just as important, an obligation to delete it? The third is operational need: storage cost, and whether old data clutters search and slows people down. The fourth is historical need: would keeping it support trend analysis or help you spot recurring issues over time. A good recommendation balances these rather than letting one voice win by volume.

• Chris (the Support Operations Lead): These closed tickets are eating storage. Can we just delete everything older than a year?
• Jake: Maybe, but let's not start with "delete." What still uses them? Does support reference old tickets, and is there any rule about keeping them?
• Chris: Support pulls them occasionally. I'm not sure about rules.
• Jake: That "not sure" is exactly what I'd check before we touch anything. If there's a legal hold or a retention obligation, deleting could be a real problem.
• Chris: So who actually decides?
• Jake: We propose a duration based on the needs, then legal confirms there's no obligation we're missing. I document it, they sign off on the regulated part.

Notice that "I'm not sure about rules" is the flag, not an annoyance. Legal uncertainty is your cue to slow down and consult, not to guess.

Once you've weighed the needs, your deliverable is a clean recommendation, not a unilateral ruling. A complete retention decision summary names five things. The owner is the person accountable for the decision. The trigger is the event that starts the retention clock (for support tickets, that's ticket closure, not the date you happened to look). The duration is how long the data is kept after the trigger. The exception path covers what overrides the clock, most commonly a legal hold that freezes deletion. And disposal responsibility names who actually removes the data when the period ends, so disposal doesn't quietly become nobody's job.

Frame the whole thing as a recommendation for review, the same way you framed your security handoff. And know your escalation triggers. The moment a decision touches a legal hold, regulated retention (data the law requires you to keep for a set time), or high-impact disposal (deleting something you can't get back), that's beyond a routine recommendation. Document your proposal and pull in legal or compliance before anything is deleted.

The single takeaway: retention is a deliberate decision with five named parts, never a gut-level "delete it" or "keep it." Three practices build on each other next, starting with a quick fill-in check to lock in the five parts of a retention decision summary, then a needs assessment weighing all four lenses, and finally the decision summary itself. For the next real cleanup request that lands on you, try opening with one question before anything else: "What starts the clock, and is there any reason we're required to keep this?"