L4-M4 / lesson 2 of 2
The provider and deployer investigate the scoring failure.
Start here / Watch the workplace case
2:48 · Narrated visual walkthrough · English captions and transcript
Watch for thisFollow how provider and deployer coordinate evidence, protective action and verification while the cause is still uncertain.
Scene 1 of 6
An upstream data format changes.
Scores fall and eligible applicants report rejection.
A technical change can become a people problem.
A creditworthiness system starts producing unusually low scores after an upstream data-format change. The deployer reports rejected applicants, including a cluster from one region. These observations do not yet establish the full cause, but they justify prompt investigation. Begin with the people affected and the possibility of continuing harm, not just the dashboard average.
The support team proposes waiting for the monthly review. Instead, use the agreed incident route and assess proportionate containment. That may mean suspending affected decisions or using an approved fallback. Preserve the relevant versions and records while taking protective action. The response should reduce continuing harm without destroying the evidence needed to understand it.
The provider and deployer should work from a shared factual chronology. Record awareness times, system versions, credible reports and the actions taken. Distinguish a suspected causal link from a confirmed finding. Share the necessary evidence securely and assign a coordinator. Separate private timelines can create contradictions precisely when accurate reporting and decisions matter most.
Assess serious-incident criteria and the applicable notification duties using the facts available. The relevant actor, incident category and reporting regime matter. Do not borrow one privacy deadline and apply it to everything, or wait for certainty when an earlier reporting trigger applies. Use current official requirements and the designated response team to track each obligation.
A patch restores the average score. That is encouraging, but it does not prove every affected outcome is resolved. Retest the relevant inputs and groups, investigate earlier decisions, and coordinate any needed correction or remedy. Keep the evidence versioned. The response should address both the technical failure and its consequences for the people who experienced it.
Before closing the incident, update the controls that allowed it to happen. That can include input validation, supplier-change notices and regression tests for the affected format. Assign owners and verify that the changes work. In the activity, distinguish a useful correction record from a statement that the issue has been fixed without supporting evidence.
After watching or reading / Think it through
Pause and form your answer, then compare the reasoning. This reflection is not scored.
Retest affected inputs and groups, investigate earlier decisions and coordinate any necessary correction. Keep a shared chronology and evidence of effective controls. Restoring an average alone does not establish that affected outcomes have been resolved.
The ideas below explain coordinated response and corrective action. In the written example, decide how to handle uncertainty, separate timelines and the patched system.
Certain widespread infringements and specified infrastructure incidents have a two-day outer limit.
Death-related incidents have a ten-day outer limit and an immediate causal-suspicion trigger.
Use the exact categories in Article 73(3)-(4). Do not apply the ten-day death limit to every injury, or the two-day limit to every outage.
An initial report can be followed by completion where the rules allow.
A high-risk creditworthiness system starts producing unusually low scores after an upstream data-format change. A deployer reports that eligible applicants were rejected, including a cluster from one region. The provider has not yet established the cause. The support team proposes waiting for the monthly dashboard before escalating.