The Access Request Gives You One Month. The Data Map Was Signed Off Years Ago.

The request lands against a map somebody finished

An access request reaches the privacy inbox and a clock starts running. Under the General Data Protection Regulation the controller must respond without undue delay and in any event within one month of receiving the request. Article 12(3) allows that period to be extended by two further months where necessary, taking into account the complexity and the number of the requests, and it requires the controller to tell the person about the extension, with the reasons for the delay, inside that first month. The right of access is Article 15; the clock and the notice are Article 12(3). Answering means knowing everywhere a single person's data lives.

There is a data map for this. Somebody interviewed the business units, reconciled the answers against the discovery results, and produced an inventory of where personal information sits. It was accurate the day it was signed.

The estate moved after that. A department adopted an application without telling anyone who maintains the inventory. A migration completed and left the records in the new location and the old one. An acquisition closed and its file shares arrived attached to nothing.

The map updates when somebody updates it, so the answer gets assembled by a search, run by people working from memory under a deadline they did not choose. The changes that put a map out of date are the ordinary ones.

• A business unit buys an application holding customer records on a card, and never registers it as a data store
• A migration completes and the records sit in the new location and the one they were meant to leave
• An integration feeds a warehouse, putting personal information in a second copy another team governs
• A backup and archive tier holds versions of stores that were cleaned up in the live estate

The map described the company accurately on the day it was signed. Nothing in it noticed the department that bought an application on a card.

A store level map cannot answer a question about one person

A second gap survives even when the inventory is current. A data map lists stores. This site collection holds HR records, this database holds customer accounts. Every line is true, and the request asks a question at a different resolution: where does this one person appear.

Getting from the store to the subject needs an identifier, and the estate keys on a different one in each place. The HR system knows an employee number. The CRM knows a customer ID. The support desk knows whatever the caller typed. A search running on one identifier misses every store keyed on another, and the miss is silent.

Then there are the stores where the person is present and unindexed. A name in the body of a support ticket. A scanned attachment. A meeting recording and its transcript. Retrieval from those is a different technique from a query.

Both platforms carry a module built for this question, and each has a scope worth knowing before the work is planned. On the Microsoft side, subject-level retrieval runs through Priva Subject Rights Requests, with eDiscovery and Content Search underneath it, across Microsoft 365. Purview's data map covers the stores outside that boundary and classifies them at the asset and column level, which is the level classification operates at. Resolving an asset to one person's records is the step after it. Securiti automates subject requests across the stores connected to its data graph.

Both modules consume the same input, and it is information the organization holds about itself: which identifier each store keys on, and which system resolves a person to it. Recording it takes about a page per store, and it is the page that gets left out of scope. Five things on it turn an inventory into something a request can be run against.

• The identifier the store keys on, and whether it sits in a structured field or in free text
• The system that resolves a person to that identifier, and who can run it
• Whether the data sits in indexed fields, document bodies, attachments or recordings
• The named individual who runs the search, and who covers when they are away
• Where copies exist: a warehouse, a reporting extract, a backup tier, a vendor environment

The search you can run and the answer you can stand behind

A manual search under time pressure can produce the data. People are resourceful and a deadline concentrates attention. What it produces less reliably is a boundary anybody can describe afterward. Two competent people searching the same estate return different sets, and both are working in good faith, because each was working from their own definition of scope. When the response goes out, the sentence saying this is everything is doing more work than the evidence behind it.

The record of the search is the artifact that holds the weight, and it costs almost nothing to keep while the search runs. Which systems were queried, with which identifier, on which date, by whom. Which systems were knowingly left out, and why: a store where the subject could not appear, a backup tier retrieved under a separate process.

Whether a response is timely and whether it is adequate belong to counsel and the privacy office. Whether the evidence exists to say anything about completeness belongs to the security team, and it gets settled long before a request arrives. Four things come out of every search, written down as it happens.

• The systems queried, the identifier used in each, the date, and the person who ran it
• The systems excluded, with the reasoning recorded at the time and by whom
• Every query that returned nothing, marked as a genuine absence or an identifier that failed to resolve
• What was found, where, and what was handed to the privacy office

Two competent people run the same search and hand you two different sets. Which one goes to the regulator is currently decided by who was free that week.

Tie the review to what changes the estate

On the three Purview and Securiti data security posture engagements CWS has delivered, the inventory started aging the day it was produced, because the estate kept moving while the program worked the findings. Both platforms rediscover what they are pointed at, on whatever schedule they are given. Whether the map stays usable depends on somebody connecting it to the work that changes the estate, and that work happens in your organization.

Map maintenance gets scheduled the way a policy review gets scheduled, annually, with a named owner and a date. That sets a ceiling on how old the document gets, and it works against drift that accumulates evenly. Estate change arrives in events, and one acquisition can move more of the estate over a weekend than a year of ordinary work.

The maintenance worth building attaches to those events, and every one of them has a project behind it with a date and a person on it. Somebody already knows the estate changed.

Most of the hooks are already in place. Procurement sees the application that goes through procurement, change management sees the migration before the cutover, and vendor management sees the processor. The application bought on a card goes around all three, and it surfaces in two other places: the expense data, where a recurring charge to a software vendor is a query finance can run on a schedule, and the identity and network telemetry that SaaS discovery reads.

Adding one question to a form those functions already run, and one recurring query against the expense data, is a smaller build than standing up a forum for the data map. That is an argued position. The maintenance cadence, the subject-level retrieval design and rehearsing a search before a request arrives are CWS recommendations. The regulation sets the deadline and the right. How you get ready for it is left to you.

The useful triggers are the ones that already have a project manager attached.

• An acquisition or divestiture closing, with the inherited stores added before integration starts
• A migration cutting over, with a recorded answer on whether the source was decommissioned
• An application going live that will hold personal information, caught at procurement
• A recurring charge to a software vendor in the expense data, which is where an application bought on a card first becomes visible
• A processor engaged or replaced, caught at vendor onboarding
• A new integration or scheduled export that copies personal information somewhere else

Tie the review to the events that move the estate. Each of them already has a date, a project and a person attached to it.

Rehearse the retrieval before somebody makes you do it

The test of a data map is a retrieval, and there is no reason to wait for a real request to run one. Pick a subject, run the search end to end, and time it.

Two ways to get a subject. An employee who consents to being the test case, which works inside HR data and gets awkward across customer systems. Or a synthetic record seeded where a real person would enter the estate: a test customer in the CRM, carried into the warehouse, mentioned in a support ticket. Keep it clear of the financial systems, because a synthetic record that reaches an invoice or a ledger is a fabricated financial record, and finance and audit will stop it on sight. That is an argued position, and it needs the agreement of whoever owns each system it touches and a reliable way to remove the record afterward.

The rehearsal returns things a document review misses, and the one worth the whole exercise is the stores that come up during the drill and appear nowhere on the map, named by whoever was asked to run the query. That group is the maintenance backlog.

A map earns its place by what it returns under a clock. Five things come out of the drill.

• The elapsed time to a complete set, against the window the privacy office works to
• The systems that needed a person to interpret the query, and the hours that took
• The identifiers that failed to resolve, and the system that should have resolved them
• The stores that surfaced during the drill and were absent from the map
• The date the drill ran, and the date the next one is booked for