Fable
The person who keeps the keys and the person who uses the keys to open doors
In the north of the city there was an archive custody company that specialized in keeping archives for enterprise clients. Clients sent documents over and signed a Custody Agreement specifying how archives would be stored, who could touch them, and when they would be destroyed. The agreement was written very clearly: the custody company could receive, classify, shelve, retrieve, and destroy archives, but the archive contents belonged to the client, and the custody company must not use them for any other purpose.
A new product manager joined the custodial company, flipped through the archives in the warehouse, and discovered a business opportunity: if the industry data in these archives could be anonymized and analyzed, it could produce a very valuable industry trend report. Excited, the product manager went to legal and asked whether this could be done.
Legal opened the Custody Agreement, read it clause by clause, and then said: the agreement allows you to process this data—receive, store, retrieve, destroy—every step for the purpose of safekeeping it for the client. The agreement does not allow you to use this data—you cannot take it for analysis, produce reports, or sell it. The boundary between processing and use is drawn very clearly in this agreement.
The product manager was unconvinced: We keep data on behalf of customers, so what is the problem with doing a little statistics on the side? Legal drew two columns on the meeting room whiteboard. The left column said "Processing," and below it were: receiving, classifying, storing, retrieving, destroying—each item an operation under customer instruction. The right column said "Use," and below it were: analysis, aggregation, modeling, commercialization, publishing—each item serving the custodian company's own purposes. A thick line was drawn between the two columns.
Legal explained: a DPA specifies what operations you may perform on data, under what security standards, and who is responsible when something goes wrong. It is a set of operational boundaries. Data usage rights specify whose purpose those operations serve—whether it is to hold the data in trust on the client's behalf, or to develop your own product. The latter requires separate client authorization.
The product manager understood. The DPA is the condition for holding the keys—you may open the warehouse and tidy the shelves, but you may not take goods out to sell. Data usage rights are the authorization for whether you can take things out and use them—it's usually a separately negotiated clause, not found in the standard DPA template.
Later, the managed services company issued a separate Data Use Authorization Appendix for clients with analytics needs; clients willing to grant usage rights signed it separately, while those unwilling simply followed the standard DPA process. The product roadmap was also split into two parts: one for managed services within the DPA scope, and one for value-added analytics services requiring usage authorization.
At the year-end compliance training, Legal said one thing: having a key and being able to use something are two different matters. The custody agreement governs the key; the usage authorization governs the thing itself.