A data subject request is not a legal problem, it is an operational one. The law says what has to happen and by when; everything hard about it is finding where the data is and proving afterwards that you looked. These are the six steps, in the order they happen, with the trap in each.
Log it, on the day it arrived
The receipt date is the only figure in the whole process you cannot reconstruct later, and every deadline runs from it. A request does not have to say data subject request, cite a law, or arrive at a special address. If a person asks what you hold about them, the clock has started, wherever they asked.
Identify the person, proportionately
You have to be reasonably sure you are not handing somebody's data to a stranger, and you must not use identity checks as a delaying tactic. Matching against the account the request comes from is usually enough; demanding a passport scan for a mailing-list enquiry is both disproportionate and a new pile of sensitive data you now hold.
Scope the ask
Access, deletion, correction, portability and opt-out are different requests with different work behind them. Ask which if it is not clear, and note that asking does not stop the clock in most regimes. Write the scope down: it is what you will be judged against.
Search, and write down where you searched
The list of systems is the deliverable nobody expects. CRM, helpdesk, mailing tool, billing, backups, the spreadsheet on somebody's drive. The value of the list is not the answer, it is that six months later you can show what was in scope of the search rather than asserting it.
Decide what does not go out
Other people's personal data in the same records, material subject to legal privilege, and information that would reveal a trade secret are the usual exclusions. Withholding is allowed; withholding silently is not. Say that something was withheld and on what basis.
Answer, and keep the record
What went out, when, and who approved it. California Civil Code section 1798.130(a)(2) requires the business to disclose and deliver, correct or delete within 45 days of receipt, extendable once by another 45 with notice inside the first period. Article 12(3) of the GDPR gives one month from receipt, extendable by two further months.
The two clocks, side by side
California: confirm receipt within ten business days, and disclose, correct or delete within forty-five days of receipt, extendable once by a further forty-five where reasonably necessary, provided the person is told inside the first forty-five. The GDPR: act without undue delay and within one month of receipt, extendable by two further months where the request is complex or numerous, with the person told of the extension and the reasons within the first month. Both clocks start on receipt, neither pauses while you check identity in the ordinary case, and both count calendar days for the response. The one figure that differs in kind is the acknowledgement, which California requires and the GDPR only makes sensible. The record keeps the receipt date, the acknowledgement date, any extension notice with its date, and the answer date, because those four are what a regulator reads first.
A request worked, from the Tuesday it arrived
A customer writes to the support address on a Tuesday asking for everything you hold about them. Logged that day: day zero. Acknowledged on the Thursday with a line saying what will happen and by when. Identified by the account the message came from. Scoped by a reply the following Monday: access, all time, all systems. Searched over two weeks: the CRM, the helpdesk, the mailing tool, billing, the shared drive, each with a date and a name. Two items withheld: another customer's name in a helpdesk thread, and an internal note that is legal advice. Answered on day thirty-one, six days inside the GDPR month and two weeks inside California's forty-five, with the withholding stated and its basis named, and the approver recorded. The record beside the guide holds that request as one row with those dates; the inbox thread that produced it holds nothing a regulator can read.
The refusals you may make, and the ones you may not
You may withhold another person's data where releasing it would be unfair to them, material covered by legal privilege, and, in most regimes, information that would reveal a trade secret, and you must say that something was withheld and why. You may refuse a request that is manifestly unfounded or excessive, particularly a repetitive one, but the refusal has to be stated with its reasons and the person's right to complain to the supervisory authority. What you may not do is invent a reason, treat a request as invalid because it did not use the right words or the right address, or let a request lapse because the person did not answer a question you asked. The record holds the refusal or the withholding with its basis, because a refusal that cannot be shown is a refusal that will be read as a failure to respond.
Questions people ask about data subject request
Does a request have to be in writing?
Not under the GDPR, where a verbal request counts. That is the strongest argument for logging one the moment it arrives, because a phone call with no record is a deadline you will miss without knowing.
Can we charge for it?
Generally no for the first request. Both regimes allow a fee or a refusal only where a request is manifestly unfounded or excessive, and repetition alone does not make it so.
What if the data is in backups?
Say so. A deletion request generally reaches live systems immediately and backups on their normal rotation; the honest answer is the retention period after which the backup copy goes, and that is a figure you should know.