Responsible Dataset Sharing

Assess the request before sharing A practical decision aid for data owners Share only when the purpose, sensitivity, intended audience, and permitted use are understood. If any of these are unclear, pause and consult your designated data-governance or privacy role before providing access. This worked example uses Northstar Works, a fictional multi-team organization considering a request for service-desk data. The examples below help frame questions; they do not establish approval rules. Compare the request with the purpose Illustrative situations, not automatic approval decisions. Monthly issue themes: the service team requests a summary grouped by month and issue category, with no direct identifiers. Check whether the summary is sufficient, whether small groups could identify people, and whether the recipient's use is permitted. Consider a limited summary view; confirm the access method and permitted use with the responsible governance role. Row-level service-desk records: the request includes names or contact details, or the requester cannot explain why those fields are needed. Direct identifiers and unclear field needs require closer review; a stated internal purpose alone does not establish permission. Pause access. Clarify necessity, sensitivity, and permitted use with the designated data-governance or privacy role. A recipient proposes combining the dataset with another source or sharing it onward. Combination or onward sharing can change identifiability, audience, and risk; check whether the original permissions cover the new use. Do not assume the original access covers the changed use. Obtain guidance before combining or redistributing data. Check the request and dataset together Work through these observable questions before selecting an access path. Purpose Can the requester state the decision or analysis they need the dataset to support, and why this dataset is suitable? Sensitivity and identifiability Have you checked the available classification and whether direct identifiers, sensitive fields, or combinations of fields could identify someone? Audience and access Are the recipient roles and intended audience named, and is there an approved access method for that audience? Minimum useful fields Can the purpose be met with fewer fields, aggregation, or a less detailed view than the requested row-level records? Permitted use Is the requested analysis, retention, combination, and any onward sharing covered by the applicable permissions and guidance? Change and review Is a review date agreed by the responsible owner, with a clear trigger to revisit access if the purpose, audience, or dataset changes? When to pause and ask for guidance Do not infer permission from a familiar dataset or an internal recipient. The sensitivity classification is missing or unclear. What should I do? Pause the share. Ask the designated data-governance or privacy role to help interpret the applicable classification and handling guidance before access is provided. I found an unexpected sensitive field after reviewing the request. Do not send the dataset as originally described. Clarify whether the field is necessary and how it should be handled with the responsible governance or privacy role; consider whether a narrower view can meet the stated purpose. The requester is outside the organization, or asks to share the data onward. Treat this as an exception to the internal-sharing example. Pause and consult the designated governance or privacy role about the recipient, permitted use, and applicable organizational requirements. The purpose changes after access is discussed or granted. Reassess the purpose, audience, fields, and permitted use before continuing under the changed purpose. Do not assume prior access covers a new analysis or recipient. I cannot tell whether combining sources or reusing the data is permitted. Do not proceed on assumption. Describe the proposed combination or reuse and ask the designated data-governance or privacy role for guidance. A short assessment sequence Record the reasoning and hand off unresolved questions before access is provided. Clarify purpose and audience Write down the requested outcome, recipient roles, and who will use the information. Inspect sensitivity and rights Check the dataset's classification, fields, identifiability, and available guidance on permitted use. Choose an approved access path Use an access method recognized by your organization for the recipient and dataset. If the suitable method is unclear, ask the responsible governance role. State limits and review timing Make the permitted purpose, audience, field limits, and any restrictions clear. Agree a review date with the responsible owner and revisit sooner if the purpose, audience, or dataset changes. Worked example: service-desk issue themes A purpose-specific view can be more appropriate than row-level access. At fictional Northstar Works, a service team asks to compare monthly issue themes across its support categories. The data owner first checks whether a monthly summary can answer that question without names, contact details, or individual records. The owner then checks whether small groups in the summary could still identify people, whether the recipient's analysis is permitted, and which approved access method fits. If those checks are unclear, the owner pauses and consults the designated data-governance or privacy role before sharing. If the summary is suitable and the use is confirmed, the responsible owner and recipient agree a review date. There is no preset deadline here: timing should reflect the dataset, purpose, and the organization's approved practice. Ownership and follow-up: the data owner is responsible for assessing the request and arranging its review; the designated governance or privacy role is the escalation route for uncertain classification, permissions, or exceptions. Revisit the assessment when the purpose, audience, fields, or dataset changes.