Definitions and Data Classifications
Section Notes
Purposes. Agreed upon definitions are key to any legal or policy regime. Definitions allow practitioners to classify technologies and standardize operations. A core set of definitions reflecting municipal uses of Data will be vital to standardizing practices across departments and jurisdictions. This Section seeks to establish definitions and Data classifications to standardize language and approaches to interdepartmental, inter-jurisdictional, and other external data sharing.
Prominent Challenges Addressed. The initial working group that led to the MetroLab Data Governance Task Force identified several scenarios, challenges, and considerations regarding “definitions” and “data classifications,” including:
- Clearly distinguishing “data” from other information or facts/putting data in context.
- Addressing “hidden data” (for example, but not limited to “metadata”)
- The need to have definitions and data classifications that (i) apply in various “Data Governance” scenarios, taking into account the “life cycle” of data creation, collection, storage/retention, transfer and uses, and (ii) are susceptible to consistent application.
- Complexities in endeavoring to define “Informed Consent” in the context of “opting in” or “opting out” on sharing/uses of one’s data.
- Gauging the desired extent of classifications of various types of data.
Definitions
For purposes of this Policy, the following terms shall have the following respective meanings:
Applicable Third Party: An individual or organization, other than a Jurisdiction employee, engaged by contract or otherwise working with or for the Jurisdiction in any one or more aspects of Data Handling.
Chief Data Officer: A Jurisdiction employee designated by the Controlling Authority to perform the functions of a “Chief Data Officer” set forth in Section 5.
Community Advisory Board (sometimes herein referred to as the “CAB”): The group established and maintained to provide well-informed, timely, and independent advice to the Jurisdiction on significant Data Handling matters in accordance with Section 5 of this Policy.
Community End User Testing Group (sometimes herein referred to as the “CEUTG”): The group responsible for providing feedback regarding the use and accessibility of the Data resources, websites, applications, and other citizen interfaces, through an Open Data Program or otherwise, as described in Section 5.1
Controlling Authority: The individual(s), body, or other entity with the legal authority to make a decision on behalf of the Jurisdiction with regard to adopting a policy, designating an individual, body or other entity to serve a function, or other significant matter described in this Guide. 2
Convener: The person or institution designated to lead the administration of the Community Advisory Board as provided in Section 5.
Data: A subset of information, whether quantitative or qualitative, that is regularly used by, maintained by, created by or on behalf of, and possessed, owned, or licensed by the Jurisdiction in non-narrative, alphanumeric, or geospatial formats. Data are an asset independent of the systems or formats in which they reside.3
Data Governance: The policies, practices, and mechanisms adopted by a Jurisdiction to manage its Data Handling.
Data Governance Oversight Committee: The committee established and maintained as such in accordance with Section 5.
Data Governance Principles: The principles set forth in Section 2 of this Guide and such other principles regarding governance of Data Handling that the Jurisdiction adopts.
Data Governance System: The processes and procedures set forth as such in Section 5.
Data Handling: The collection, creation, storage, use, transfer, dissemination, and disposal of Data, and use of Data Platforms, and related security, risk mitigation, and breach damage containment measures.
Data Intermediary: An individual or organization, other than an employee or unit of the Jurisdiction, that assists the Jurisdiction in collecting, storing, disseminating, communicating, analyzing, or disposing of Data sought for use or sharing by the Jurisdiction.4
Data Security Policy: The “Data Security Policy” described in Section 3.B.2.
Dataset: A collection of Data organized or formatted in a specific or prescribed way. Typically, a Dataset consists of one or more tables and is stored in a database or spreadsheet. Files of the following types are not Datasets: text documents, emails, messages, videos, recordings, image files such as designs, diagrams, drawings, photographs, and scans, and hard-copy records.
Data Platform: The methods, machinery, software, and related tools and systems utilized by the City or Applicable Third Parties to collect, store, use, or make public any Dataset, including, without limitation, those utilized in any Open Data Program.
De-Identify: To remove all Personally Identifiable Information from Data.5
Encrypted: Any Data format with content designed to be protected and accessible only by private parties specifically intended as an audience.
Machine-Readable: Any Data format in which a computer can read and process information.
Open Data: Data made open and freely available to all online in a Machine-Readable, open format that can be easily retrieved, downloaded, and reused utilizing readily available and free Web search applications and software.6
Open Data Program: A City program dedicated to making specific Datasets available as Open Data to the public, including, without limitation, programs that engage civic technologists, the research community, and other partners to make use of such Datasets in support of the program’s goals.7
Open Data Programs Manager – The Jurisdiction employee designated by the Controlling Authority to manage the City’s Open Data Programs and to perform the functions pertaining thereto described in Section 5.
Payment Card Industry (PCI) Data Security Standard: Standards adopted by the Payment Card Industry Security Standards Council to protect payment information for safe financial transactions.8
Personally Identifiable Information (“PII”): information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular individual (sometimes shortened to “personal information”). Examples include but are not limited to:
- Identifiers such as a real name, alias, postal address, unique personal identifier, online identifier, Internet Protocol address, email address, account name, social security number, driver’s license number, passport number, or other similar identifiers.
- Biometric information.
- Internet or other electronic network activity information including but not limited to, browsing history, search history, information regarding an individual’s interactions with a government website or application.
- Geolocation data.
- Audio, electronic, visual, or similar information.
- Professional, educational, or employment-related information.
- Inferences drawn from any of the information identified in this subdivision to create a profile about an individual reflecting their preferences, characteristics, psychological trends, predispositions, behavior, attitudes, intelligence, abilities, or aptitudes.
Note: Cybersecurity insurance or other policies may have different definitions of PII that could impact policies and processes.
Principal Data Handling Administrator: The Chief Data Officer or other individual designated by the Controlling Authority to be primarily responsible for oversight of adherence to this Policy.
Privacy Laws: All laws containing provisions for the protection of a person’s privacy by regulation of the collection, storage, use, and/or release of any PII of such person.
Public Disclosure Law(s): All open meetings, open records, public records, freedom of information, or similar laws pertaining to disclosure, notice, or other transparency requirements to which any Data Handling activities of the Jurisdiction are subject.
Re-Identify: To convert anonymized or De-Identified Data into PII.
Sensitive Data: Information that the Jurisdiction determines should be safeguarded and protected against unwarranted disclosure for legal or ethical reasons, for reasons pertaining to personal privacy, or for proprietary considerations, and includes, without limitation, PII. 9
Unit Data Steward: The Jurisdiction employee designated by the Chief Data Officer as the person in a Jurisdiction agency or department responsible for performing the functions of a “Unit Data Steward” described in Section 5.
Data Classifications Recommendations
Note: The following Data classifications recommendations in this subsection assume that the Jurisdiction’s Data Handling experience is fairly mature. An alternative set of recommendations for Jurisdictions with less mature Data Handling experience is presented at Alternative Data Classifications for Less Mature Data Handling Systems.
If Data is not already classified by a third party, cities and counties should establish Data classifications by level of sensitivity. Sensitivity levels inform data collection, retention, storage, dissemination, and disposal. Classifying data protects privacy, limits data misuse, maximizes data usage, and facilitates sharing of open data sets. The following suggested classifications could be established by rule or practice and incorporated into training, security measures, and data-related decision-making. Data classifications should be reviewed regularly and updated as necessary. These classifications will also inform the parameters of a local government’s Data Security Policy.
Level 0—Open
Any Dataset regularly published in Machine-readable format by Jurisdiction or its Units on the Jurisdiction’s website, or otherwise treated as Open Data is considered “Level 0—Open” unless the Jurisdiction or a Unit makes a proactive determination to raise the classification.
Level 1—Public, Not Proactively Released
Data available for public access or release, not subject to any restrictions under any Public Disclosure Law or Privacy Law.
Level 2—For Internal Government Use
A Dataset that the Jurisdiction determines is subject to one or more Public Disclosure Law exemptions, but is not highly sensitive, and may be distributed within the Jurisdiction government without restriction by law, regulation, or contract. Data that is normal operating information but is not proactively released to the public. Viewing and use is intended for employees; it could be made available Jurisdiction-wide or to specific employees in a department, division, or business unit. Certain data may be made available to external parties upon their request.
Level 3—Sensitive
Data intended for release on a need-to-know basis. Data regulated by privacy laws or regulations or restricted by a regulatory agency or contract, grant, or other agreement terms and conditions.
Level 4—Protected
Data that triggers a requirement for notification to affected parties or public authorities in case of a security breach.
Level 5—Restricted
This data poses direct threats to human life or catastrophic loss of major assets and critical infrastructure (e.g., triggering lengthy periods of outages to critical processes or services for residents). Before classifying data as Level 5 Restricted, you should speak with leadership in your Unit and the Jurisdiction’s Chief Data Officer.
A Data classification flowchart and examples of each category of Data follows below:10
Doing public good with Data requires that the Data is of sufficient quality/integrity, is properly accessible, and is stored safely.
While cities, counties and states use many rules and regulations, a common first step is to establish privacy principles, often by way of resolution passed by the Jurisdiction’s governing body.
A core set of definitions reflecting municipal uses of Data will be vital to standardizing practices across departments and jurisdictions.
While protecting data from outside threats is a major concern in a Jurisdiction’s Data Governance, just as important is standardizing internal departmental procedures to safeguard data throughout its lifecycle.