A Meraki-assisted occupancy dashboard for libraries only needs site-level counts. Which storage privacy practice should the app follow?
Select an answer to reveal the explanation.
Short Explanation
If the dashboard needs a headcount, do not warehouse everyone’s names and GPS breadcrumbs. Minimization keeps storage privacy exposure as small as the feature truly requires.
Full Explanation
Data minimization persists only what the feature needs—for example aggregated site counts—rather than raw usernames and fine-grained GPS tracks. A smaller retained identity surface shrinks blast radius if the reporting store leaks and can still answer the municipal dashboard question without surplus personal detail. Storing every raw username and fine-grained GPS track indefinitely for “possible future features” invents retention without purpose limitation and balloons privacy risk over time. Duplicating full client probe payloads into the reporting database “just in case” copies excess personal telemetry into a second system that may be less hardened and more widely queried. Claiming minimization applies only to network packets, not storage, misunderstands privacy: stored trails remain personal data long after the packet is gone. Exam caveat: aggregation must be checked for re-identification—small sites plus precise timestamps can still pinpoint individuals if high-resolution leftovers remain in the schema. Operational check: review the reporting schema and a sample of rows to ensure no raw identity or precision location fields exist beyond what the published civic feature requires.