The Export Endpoint and the Link-Shared Spreadsheet
You are a junior developer at a 12-person software house in Muscat. Three weeks into a fixed-price contract worth OMR 18,000, you are building a beneficiary registration system for a government office. The demo to the client's director is on Monday; the sprint ends Friday. While preparing demo data you notice that GET /api/beneficiaries/{id}/export returns any beneficiary's full record, including national ID number, phone, bank account and a disability flag, to any authenticated user, whatever ward they are assigned to. There is no audit log on the endpoint. You also find a spreadsheet in the team drive containing 312 beneficiaries' national ID numbers, created by a colleague for load testing, and the folder is link-shared to anyone with the link. Your team lead says both issues are 'known, logged for phase 2' and tells you not to raise them during the client demo because 'they will panic and hold the milestone payment'. The contract carries a data-protection schedule requiring the supplier to notify the client of any personal-data breach without undue delay.
1. Set out what you do in the next 24 hours, in order, and what you deliberately do not do.
Read the worked answer
Hours 0 to 2: stop the exposure, because that part is inside my authority. Remove the link share and move the spreadsheet into a restricted folder, or delete it if the load data can be regenerated synthetically. Record the timestamp, the original sharing settings, and how long it had been shared, which the drive audit log will show. None of that needs approval and all of it is reversible.
Hours 2 to 4: write it down. A short factual note: what the export endpoint returns, what an attacker needs (any valid login), how many accounts exist, the 312-row file, dates, and who I told. Facts only, no accusation. This note protects both the beneficiaries and me if the story changes later.
Same day: raise it in writing to the team lead. Restate the contract's notification clause and ask for two decisions: whether the client must be notified, and whether the export endpoint is disabled before Monday. Ask for the answers in writing.
Within 24 hours: escalate if there is no decision. Project manager, then the firm's data-protection contact. The professional duty here is not loyalty to the team lead; it is the safety of 312 identifiable people who never consented to this risk.
What I deliberately do not do: raise it in the client's Slack channel, quietly patch the endpoint and say nothing (which destroys the evidence needed for a notification decision), or promise the client anything on my own authority.
2. How would you communicate this to the team lead, and what would you say to the client if you were asked directly during the demo?
Read the worked answer
To the team lead: sized, not emotional. 'The export endpoint lets any logged-in user pull any ward's records, including national IDs and bank accounts; we have roughly 40 accounts. Separately, 312 national IDs sat in a link-shared folder from 3 March. The contract says we notify without undue delay. I have removed the share. I need a decision today on disabling the export before Monday, because that is a two-line authorisation check, not a phase-2 redesign.'
Separate the cheap fix from the expensive one. Ward-scoped authorisation on a single endpoint is perhaps half a day; audit logging and a full access review belong in phase 2. Conflating them is exactly how 'phase 2' swallows the thing that has to happen before the demo.
To the client, if authorised, or if the notification duty is engaged. Structure it as: what happened, who is affected, what we have already done, what remains, and when we will confirm. No speculation about whether anyone downloaded anything, no naming of the colleague, no minimising adjectives.
In the demo itself. If the director asks whether the system is secure, I neither lie nor improvise. 'There is an access-control issue in one export function that we are fixing before go-live' is a complete sentence. A milestone payment is not worth a false statement to a government client, and a junior developer is still the person who made it.
3. Suppose the team lead refuses to act and the demo goes ahead. Describe your escalation path, what you document, and how you weigh the risk of damaging your own position.
Read the worked answer
The ladder, in order, each step in writing: team lead, then project manager, then the firm's director or data-protection contact, then the professional body's ethics advisory service. At every step I state the same facts and the same ask, so nobody can later claim they were hearing a different story.
Ask for a written instruction if I am overruled. 'Please confirm by email that the decision is to leave the export endpoint live through Monday.' A manager who is confident will put it in writing; a manager who will not is telling me the decision is not defensible. A written instruction does not dissolve the risk and does not transfer my professional responsibility, but it does document that I raised it at the time.
Document my own record: notes, emails, dates. Without copying beneficiary data out of the system, because the evidence I need concerns the system and the process, not the 312 people.
If the endpoint stays live and the client is not told, I would treat it as a matter I cannot resolve internally and use the external channel the profession provides, telling my employer that I am doing so. Whistleblowing protection generally covers disclosures to a regulator made in the public interest; it does not reliably cover leaking to the press, which I would avoid.
The self-check before escalating: am I acting because 312 people face real harm, or because I want to be proved right? If it is the second, I should slow down and tighten the facts, but I should still not sign off on the release.