PrerequisiteCompleted Module 2 (Process & User Immersion), with an updated current-state process and immersion summary
0 / 3 completed
Learning objectives
Re-test current accounts' and roles' effective permissions to confirm they still match the IL 202 access matrix.
Re-check the actual data scope in use to find any scope creep.
Verify item by item that IL 202 Readiness Review's conditional items are truly closed, not just marked closed on paper.
Review is re-verification, not redoing the work
60 min
Re-verify effective permissions
The access matrix completed at IL 202 is a snapshot at a specific point in time. Between Readiness Review approval and the IL 301 pilot starting, accounts may have left, roles may have changed, and systems may have been upgraded. The first step of technical and data review is to re-test permissions with the actual current accounts, not assume the matrix is still correct.
Effective-permission re-verification checklist
Item
Re-verification method
Accounts still exist and are active
Confirm the current status of every pilot team member and every AI tool service account
Role scope unchanged
Log in with the actual account and test that it is still read-only or the originally approved minimal privilege
Revocation mechanism still works
Re-drill a revocation and confirm it takes effect immediately, not with a multi-hour delay
Third-party or outsourced accounts
For any outsourced vendor accounts, confirm the contract and data-use scope are still valid
Warning
Common mistake: skipping re-verification because "IL 202 already approved this." Approval is a judgment at a point in time, not a permanent grant; if permissions or data scope have changed without re-approval, this is the needs_revalidation situation the IL SDD describes: an old approval cannot be reused to keep moving forward.
Key takeaway: IL 202's approval is a snapshot, not a permanent guarantee; technical and data review must re-test with the accounts as they actually exist "now."
60 min
Re-check the data scope
Data scope creep is usually not deliberate rule-breaking: it happens when a team, solving an immediate problem, casually adds one more data source or keeps one more log. Technical and data review must actively check whether "what's actually used now" has exceeded the scope IL 202's data inventory approved.
Data-scope re-check items
Item
Description
Data source list
Compare against the IL 202 data inventory to confirm every currently connected source is on the approved list
New fields or logs
Check whether unapproved personal-data fields or detailed logs were added for debugging or monitoring
Retention period
Confirm current retention/deletion settings match the approved retention policy
External transfer
Confirm data is not sent to an unapproved external service (e.g. a third-party monitoring tool used for debugging)
A common scope-creep scenario
For debugging convenience, the technical team copies full customer-service conversation logs: including customer name and phone number: into a separate spreadsheet used for quickly searching problem cases.
The correct approach
Identify the problem
This debugging spreadsheet is outside IL 202's approved data scope and retention period: it is an unapproved data copy.
Act immediately
Delete the unapproved copy; if debugging genuinely needs it, reproduce the issue with de-identified or synthetic data instead.
Strengthen the process
Explicitly list "no unapproved copies" in the technical review checklist, and periodically audit temporary debugging data.
Flag needs_revalidation
If a new access pattern is genuinely needed for debugging, submit it to the governance reviewer for re-approval rather than doing it first and asking later.
Key takeaway: Scope creep usually comes from "debugging convenience": technical review must actively look for it, not wait to discover it after the fact.
60 min
Verify conditional items are genuinely closed
A conditional status on the IL 202 Readiness Review represents "ready with conditions," and every one of them should have clear closing evidence. Before IL 301 begins, verify item by item whether these conditions are truly closed, rather than just trusting a status field that says "closed."
The technical administrator claims it was completed and re-drilled by 3/15
Require the drill record and the actual revocation timing, not just a "completed" checkbox
Privacy-readiness personal-data tagging gap
The privacy owner claims tagging was completed and re-assessed
Spot-check the data flow map to confirm personal-data tagging genuinely covers fields like customer name and contact info
1Exercise: technical and data re-verification checklist Using SYN-CS-001, complete a technical and data re-verification checklist.
2Step 1 List every conditional item from the IL 202 Readiness Review.
3Step 2 For each one, fill in a "claimed closure" column and a "how you would re-verify" column.
4Step 3 Flag whether the current data scope shows any sign of scope creep; if so, record it as needs_revalidation.
5Step 4 Hand the full checklist to the governance reviewer for confirmation as a precondition for entering Module 4's solution sprint.
Check yourself
The team discovers that a technical staffer, for debugging convenience, copied a full conversation log containing customer name and phone number into an unapproved debugging spreadsheet. Per this module's principles, what is the most appropriate response?
Key takeaway: "Closed" is a claim, not evidence; the value of technical and data review lies in demanding a concrete re-verification result.
