A useful data map records what information the product collects, whose information it concerns, why it is needed and where it goes. Include vendors, copies, access and retention. This reveals obligations that an architecture diagram focused only on servers can miss.

Begin with the purpose rather than a list of everything technically collectable. Each data element should have an explainable connection to a product or operational need. New uses and new recipients require a fresh review of that connection and the applicable responsibilities.

Security concerns protection against events such as unauthorized access, loss or misuse. Privacy concerns appropriate collection and use in relation to people and applicable obligations. A technically secure database can still contain information collected without a justified purpose.

Consider both in product design. Restrict access, protect copies and prepare incident processes, while also examining minimization, transparency and retention. The historical privacy slides are a starting point for questions. Current requirements depend on jurisdiction, context and the people whose data is involved.

Minimization can concern the amount, precision, duration and location of the data. A feature may work with a broad age range instead of a birth date, a local calculation instead of central storage or short-lived data instead of indefinite retention.

Evaluate the effect on usefulness alongside the reduction in exposure. The goal is a specific design decision supported by the purpose. Document why the retained information remains necessary and how deletion works across logs, backups and vendors.

Sending data to a vendor creates dependencies on that vendor’s practices and on the agreement governing the service. The team needs to understand access, onward use, location, deletion and incident handling.

Assign responsibility for actions the product promises to people. A notice is ineffective if no process can locate or delete relevant records. Test the workflow across systems and make sure product changes trigger a review. The source’s “privacy by design” discussion places these questions during development rather than after launch.

The map follows the data life cycle for Relay Scheduler. The right-hand column is where most findings sit: retention and vendor coverage, not the main database.

Retention periods are an illustrative policy. HIPAA status, BAA scope and retention rules depend on current law, the clinics' agreements and review by qualified counsel.