# Prioritisation and the 30, 60, 90 day plan How findings become an ordered plan that the same evidence always produces. ## Severity - FAIL: wrong data, data used without permission, money or access at risk now, or a decision that can no longer be made in time. - WARN: a plausible defect that needs an owner decision or more evidence. - PASS: the check ran on the stated evidence and found nothing, or found the documented, correct state. - NOT CHECKED: the evidence was unavailable. State the reason and the export that would close it. - Downgrading a FAIL requires citing the accepted exception in `decisions.md`, with its date and owner. ## Priority classes Assign one class per finding. The class sets the order; severity alone does not. - Class 1, customer harm or data used without permission: unsubscribes reaching the sending tool after the next send; people data sent to an ad platform with no consent rule; an unverified AI app reading mailboxes; two tools sending the same onboarding email. - Class 2, material data loss or access risk: a critical tool whose only admin is an agency; an integration on a departed person's credential; a dormant top-level admin; missing order forms with a notice boundary inside 90 days; two writers on a lifecycle field. - Class 3, measurement for a current decision: a tracking gap behind a budget decision; duplicate account IDs in the CRM behind pipeline reporting. - Class 4, manual work: a weekly CSV upload; a manual reconciliation. - Class 5, commercial optimisation: seat reclaim, tier right-size, renegotiation, consolidation of overlapping tools without customer impact. Inside a class, order by impact, then confidence, then effort, each written as words (high, medium, low) with a reason. Never multiply scores into one number; it looks more precise than the evidence. ## Dependencies Show them in the plan as "Dependencies: P3" so nobody starts out of order: - Identity before new segments: no new audience or segment on an email-only or duplicated key. - Eligibility before more automated sends: suppression and consent flows pass their tests before any new journey goes live. - Measurement fixes before the consolidation decisions that rely on them: do not retire an analytics tool on numbers that are themselves broken. - Access before AI: no write-capable AI connection until the access check is ready. ## Quick wins A quick win is one setting or one seat, reversible, with no dependency, an available owner, no customer-facing change and no contract action. A contract action means written notice, an order-form change or a reduction at a term boundary. Cancelling a self-serve monthly subscription whose reduction rule is any_time, after the owner confirms which one stays, is a quick win. Examples: - Remove the admin role from a dormant admin after the owner confirms. - Cancel a duplicate card subscription that is reducible any time, after the owner confirms which one stays. - Add an alert owner to a critical connection. - Record a missing owner role in the register. Not quick wins: anything that changes what customers receive, needs a contract action, or depends on another fix. ## Bucket rules Windows count from the audit's as-of date. - Act now, before the report: every CON04 FAIL, every review-by date within 14 days and every INV02 FAIL that stack_inventory.py lists under "Act now". Tell the user the same day, then place each item in its window. - Days 0 to 30: every class 1 and class 2 FAIL; every review-by date inside 30 days (including overdue ones); missing order forms (CON01); quick wins. - Days 31 to 60: flow, identity and tracking repairs; replacement tests that must finish before a decision; review-by dates from day 31 to day 60. - Days 61 to 90: cutovers that passed their tests; retirements (access, tokens, webhooks, embedded forms, notice, next invoice); the new-tool intake rule; re-tests of closed FAILs; review-by dates from day 61 to day 90. - Later: review-by dates beyond 90 days, and large projects, each with a quarterly gate (what must be true before it starts). - Capacity: when the first window holds more than the owners can take, move class 5 items first, then class 4. Never move class 1. - Every FAIL is either in the plan or accepted by its owner with a date. ## Acceptance tests Write a test someone else can run and close without asking a question. - Bad: "improve tracking". Good: "one confirmed purchase event per order ID, with matching amount and currency, across the agreed test set of 20 orders". - Repair: the connection's four-case test passes three times in a row. - Suppression: an unsubscribe in either tool reaches the other within the required freshness in three of three tests. - Retirement: no login, job, API call or invoice for 30 days after cutover, with INV08 clear on the next run of stack_inventory.py; the replacement passed the agreed cases; the written non-renewal acknowledgement is filed; the next invoice is absent. - Access: in a fresh user export the admin count sits inside the band, every admin on a critical tool shows MFA enforced, and no enabled account belongs to a deactivated identity provider user. ## Savings statement - Cash through a stated date, run-rate after commitments end, and released capacity, reported apart. - No cancellation is counted before its effective date. Prepaid terms save nothing until they end. - Capacity is reported as hours with the work they move to, never as cash. ## Leadership summary One page, in this order: - Decisions needed, with their deadlines. - Customer harm found and its containment. - Money, in the three figures above. - What was not checked, and what would close it. ## Cadence after the audit (planning defaults) - A renewal review at each review-by date in the calendar. - A monthly re-run of stack_inventory.py on fresh spend and identity exports, compared with the last run. - A quarterly access review for critical tools: admin band, external admins, dormant admins, AI connections. - A full audit yearly, or after an acquisition, a new product line or a platform migration. - Recurring checks for closed findings belong to tracking-monitoring-and-incidents (planned).