Section 2: A Contract With a Clock - Requirements (Functional & Non-Functional)

Executive Summary: This section turns Section 1's assumptions into a contract for the Privacy Request Orchestrator. The functional requirements cover three audiences: users who ask, the 1,200 services that act, and the privacy team that answers for the result. The non-functional requirements are written as numbers. The most important of them was set by the law rather than by us: a one-month deadline under GDPR Art. 12(3). We split that month into a 24-day internal budget with a 6-day buffer, write completeness down as a measurable target, and list what is out of scope and why. The section's lesson is that the requirement that matters most here is completeness by a deadline. Speed matters much less.

With the assumptions on the board, the interviewer leans back: "Fine. So what exactly are we committing to?" In most designs you choose your targets. Here one is already fixed. The regulation says a user's request is answered "without undue delay and in any event within one month of receipt." The job is to fit the rest of the contract around that month and make every line checkable.

The Functional Contract: Three Audiences

I group the functional requirements by who depends on them; each group becomes a different face of the system.

For the data subject (Lena, and two billion others)

• Submit an erasure (Art. 17) or access/export (Art. 15, with portability under Art. 20) request from account settings, the support console, or a public web form.
• Be verified in proportion to the risk. In session: recent re-authentication plus 2FA. Out of session: proportionate, never "delete on an email alone." Support-initiated deletions need two-person approval.
• Get a grace period for erasure. The account is disabled immediately, the user can cancel for 14 days, and hard erasure follows.
• Receive an export as a downloadable archive in a structured format; its machine-readable subset of user-provided data is the Art. 20 portable part.
• Be told when we accept the request, if we extend the deadline, and when we finish.

For the 1,200 data-holding services

• A registry of personal-data holders: data categories, identifier types, owner, on-call rotation, SLA tier.
• Receive every request relevant to them. Erasure goes to all 1,200 registered holders. Access goes to the 400 source-of-truth holders, including inferred profiles such as ads interests and recommendation features. The other 800 hold derived copies (caches, search indexes, replicas, feature-store copies): they must delete on erasure but add nothing new to an export. Art. 15's supplementary information (purposes, recipients, retention and source per data category) is generated from the registry, not from per-user tasks.
• Report a per-task outcome from a fixed set of values: COMPLETED, NO_DATA, RETAINED_EXEMPT (with an exemption code), or FAILED.

For the privacy and legal team

• Legal hold: data in a hold's scope is restricted, not deleted (RETAINED_EXEMPT with code LEGAL_HOLD). The request still finishes on time with an honest notice, and releasing the hold opens a follow-up erasure for exactly that scope.
• Dashboards: open requests, deadlines at risk, stragglers by service.
• An immutable audit trail that proves the process ran. This is the accountability duty in Art. 5(2): we must be able to demonstrate compliance, not only comply.

The interviewer pushes on the third erasure outcome:

Interviewer: "Why does RETAINED_EXEMPT exist? The user said delete everything."
Candidate: "Because the right to erasure isn't absolute. Art. 17(3) lists exceptions, including legal obligations and legal claims. Lena's invoices in billing are the realistic case: a statutory tax-record obligation keeps them. The orchestrator doesn't decide exemptions: counsel approves the codes, each service registers which it may use, and the task records the one applied. The data is restricted and deleted when that retention period ends. Without it, billing must either lie with COMPLETED or stay FAILED forever."

The grace period draws the next probe:

Interviewer: "'Without undue delay.' Isn't a 14-day wait exactly that, undue delay?"
Candidate: "The account is disabled on day 0: hidden, processing stopped. Only the irreversible step waits. The window stops an account-takeover attacker deleting a victim for good, and covers plain regret. Immediate hard deletion can't be undone; a 30-day window, which some products use, leaves no time inside the month for 1,200 services to act. The window is one configuration value, for when counsel reads the clock differently or a product needs instant deletion, such as a child's account at a parent's request."

Quick check before moving on: