Data protection and governance（数据保护与治理）¶

Foundry empowers users to integrate, transform, analyze, and operationalize data across an enterprise, while securely collaborating and sharing data products. An important part of every data strategy and initiative is ensuring lawful, legitimate, compliant, and appropriate use of the data. Data protection and data governance are central concepts to using Foundry.

Data protection refers to the range of technical and organizational means available to ensure that the processing of personal data is at all times limited to that which is necessary and proportional to achieve a legitimate processing outcome.
Data governance refers to the management of enterprise data across the entire lifecycle of processing, from ingestion to access to deletion.

While privacy regulations vary around the world, most regulations require systematic and programmatic means of understanding what data an organization has in order to appropriately use and handle the data. Data protection and data governance go hand-in-hand in Foundry. This documentation outlines best practices and tools available to our customers to help facilitate adequate and appropriate data protection and data governance when processing data, including sensitive or personal data, in Palantir Foundry.

This document is meant for data administrators, data governance owners, data owners, and users who are working with sensitive data on the platform and want to understand Foundry's capabilities to protect this data.

If you have questions about data protection, data governance, or protecting sensitive data, Palantir has a Privacy and Civil Liberties (PCL) team ↗ that can provide guidance on handling sensitive data in Palantir Foundry. Contact your Palantir representative to be connected with Palantir's PCL team.

Data protection principles¶

Platform administrators and users should seek to handle enterprise data, and in particular personal or sensitive data, responsibly at all times. The Fair Information Practice Principles (FIPPs) provide a useful set of guidelines that serve as foundational principles of working with personal data that enforces privacy protection.

Fair Information Practice Principles (FIPPs)¶

Below, we provide an overview of the FIPPs, based on the OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data ↗:

The Collection Limitation Principle. There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.
The Data Quality Principle. Personal data should be relevant to the purposes for which they are to be used and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.
The Purpose Specification Principle. The purposes for which personal data are collected should be specified no later than at the time of data collection and the subsequent use limited to the fulfillment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.
The Use Limitation Principle. Personal data should not be disclosed, made available or otherwise used for purposes other than those specified, except a) with the consent of the data subject, or b) by the authority of law.
The Security Safeguards Principle. Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorized access, destruction, use, modification or disclosure of data.
The Openness Principle. There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data and the main purposes of their use, as well as the identity and usual residence of the data controller.
The Individual Participation Principle. An individual should have the right:
to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him/her/them;
to have data relating to him/her/them communicated to him/her/them, within a reasonable time, at a charge, if any, that is not excessive; in a reasonable manner, and in a form that is readily intelligible to him/her/them;
to be given reasons if a request made under subparagraphs (a) and (b) is denied and to be able to challenge such denial; and
to challenge data relating to him/her/them and, if the challenge is successful, to have the data erased, rectified, completed or amended;
The Accountability Principle. A data controller should be accountable for complying with measures which give effect to the principles stated above.

Among the common themes across these FIPPs is the need for Data Minimization, where data should only be collected ("Collection Limitation Principle") and used ("Use Limitation Principle") for explicit and authorized purposes ("Purpose Specification Principle"). Additionally, data must always be handled with security assurance in mind ("Security Safeguards Principle").

FIPPs Example¶

For example, consider the following scenario.

A financial institution (FI) may apply FIPPs when considering how to handle a new customer program required for providing a banking service.

As the FI sets up the program, the financial institution would only seek to collect personal information necessary for running the program from customers who are enrolling in it ("Collection Limitation Principle"), where all purposes are provided upfront ("Purpose Specification Principle") and the details and method of data handling are openly disclosed ("Openness Principle").

As the data is prepared for users, data owners and preparers ensure the data is regularly maintained and reviewed so that any decision pertaining to the data uses accurate up-to-date information ("Data Quality Principle") with assurances that all data is securely stored ("Security Safeguards Principle"). System-wide processes like regular audit reviews ensure the data is only used for pre-specified purposes ("Accountability Principle"). Once the data is ready for users, only authorized users who work on the data for the approved purposes have access to that data ("Use Limitation").

Meanwhile, on the consumer side, the FI allows consumers to regularly request access, delete, or correct information ("Individual Participation Principle"). Furthermore, beyond FIPPs, it may be required to adhere to other financial sector requirements on how long the data needs to be retained for compliance reasons.

In example alone, many complexities and considerations in handling data are involved. The best practices outlined in this documentation will provide an overview of the wide range of technical tools in Palantir Foundry that help operationalize these foundational principles when working with sensitive data, including personal data.

Beyond FIPPs¶

FIPPs are just a starting point for evaluating the privacy of personal or sensitive information. Principles of fairness, non-discrimination, and ethics may also be relevant to personal data processing. Different legal, regulatory, and administrative requirements may vary by jurisdiction, sector, and general norms. Consult a legal counsel or privacy expert to advise on relevant requirements.

Sensitive data classification¶

Identifying sensitive data is a critical first step. Context matters because whether certain data is considered sensitive or not depends on the relevant privacy regulations and norms.

Sensitive data here is defined as any data that is broadly classified and/or requires extra security. Some laws formally designate specific data elements as sensitive (for example, the EU's General Data Protection Regulation), whereas others are determined by the data owners or by common recognition regardless of legal status (such as Social Security Numbers). Whether data is classified as sensitive generally depends largely on the type or classification of data (e.g., personally identifiable), the types of workflows (such as limited to specific purposes), or any content (such as sensitive enterprise information) that may trigger restricted access controls.

One common example of sensitive data is Personally Identifiable Information (PII), which includes direct identifiers and other information about individuals that can be used to re-identify individuals or single them out.

Examples of sensitive information include:

Contact information: Name, email, phone number
ID numbers: Social Security number (SSN), license number, medical record number, tax identification numbers (TIN)
Biometrics: Facial signatures, fingerprints, images of individuals, DNA
Dates: Birth date, admission or discharge dates
Location information: Home address, office address, wearables location data, cell phone locations
Health information: Past, present, or future physical or mental health or condition, medications, treatments and diagnoses
Financial information: Income or assets, medical bills or payments, account numbers
Other sensitive information: Phone logs, IP addresses

Depending on the jurisdiction or field, sensitive data might be classified differently. Below are examples of some relevant data protection and privacy regulation definitions:

EU General Data Protection Regulation (GDPR) is one regulation which explicitly defines personal data. To summarize, the GDPR defines personal data as any piece of data that can identify an individual and also classifies characteristics like race and political opinions as sensitive. The formal definition is below:

Article 4(1) ↗ of the GDPR classifies personal data as:

any information relating to an identified or identifiable natural person ("data subject"); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

Furthermore, Art. 9(1) ↗ of the GDPR highlights the following types of personal data as special categories of personal data warranting additional layers of care and protection:

personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life.

US Health Insurance Portability and Accountability Act (HIPAA)¶

The US' Health Insurance Portability and Accountability Act (HIPAA) outlined in HHS’s detailed guidance ↗ is a common framework for handling healthcare data in the US. HIPAA applies to data held by health care providers and insurers, but it does not necessarily apply to other processors of the same data. To confirm, consult a legal counsel or privacy expert to advise on relevant requirements.

Under HIPAA,

Protected health information is information, including demographic information, which relates to:

the individual’s past, present, or future physical or mental health or condition,

the provision of health care to the individual, or

the past, present, or future payment for the provision of health care to the individual, and that identifies the individual or for which there is a reasonable basis to believe can be used to identify the individual. Protected health information includes many common identifiers (e.g., name, address, birth date, Social Security Number) when they can be associated with the health information listed above.

For example, a medical record, laboratory report, or hospital bill handled by a HIPAA-covered entity would be PHI because each document would contain a patient’s name and/or other identifying information associated with the health data content.

Other¶

Other relevant international data protection frameworks which could apply to your organization or project include:

Brazil - Lei Geral de Proteção de Dados (LGPD)
Japan - Act on the Protection of Personal Information (AAPI)
Canada - Personal Information Protection and Electronic Documents Act (PIPEDA)
California, US - California Consumer Privacy Act (CCPA) / California Privacy Rights Act (CPRA)
Virginia, US - Virginia Consumer Data Protection Act (CDPA)
Colorado, US - Colorado Privacy Act (CPA)

The above list is not comprehensive and explicit definitions will vary depending on local jurisdiction, region, or sector. Consult your legal, compliance, and/or data protection team(s) to understand relevant classifications of data and specific handling instructions based on applicable rules and regulations.

Data governance oversight¶

Before you start working with data in Palantir Foundry, make sure you identify relevant subject-matter experts (SMEs) and accountable authorities for data protection and data governance at your organization. Handling enterprise data, including personal and other sensitive data, comes with it a series of considerations: from legal and regulatory requirements to operationalizing organizational rules set by the platform/data owner(s).

Below are a series of common procedures to follow or check in on with your organization before starting to process data in Palantir Foundry:

Identify a governance committee/SMEs or designate a data governance lead

A governance committee does not need to be a formalized group and may take different forms for every organization. It is important to understand who in the organization is the responsible party or parties to think through, adjudicate, and help problem solve data governance and data protection questions as use of the platform evolves, use cases expand, etc.
The responsibility for ensuring data is handled appropriately typically lies with the respective data owner(s). This includes determining how basic principles of data processing outlined below should be applied to specific workflows, but also ensuring that system-wide data governance requirements can be met, such as ensuring accountable use of the platform with audit logs and configuring relevant retention policies.
These data governance requirements are commonly defined by an organization’s Data Protection Office (DPO), Information Security, Compliance, or Legal functions.

:::callout{theme="success" title="Best practice"} Consult with the respective data owner(s) or data controller to identify relevant parties who will know and can sign off on how to handle data in accordance with applicable regulations, use agreements, and other requirements. :::

Complete Required Privacy Reviews or Privacy Impact Assessment

Depending on industry, region/jurisdiction, application, or organization-specific requirements, additional documentation may be required before processing can begin. This could come in the form of an organization-specific or regulatory requirement to prepare documentation such as Privacy Threshold Assessments, Privacy/Data Protection Impact Assessments, Conformity Assessments, Privacy Statements, Record of Processing Activities, System of Records Notices (SORNs), etc.
Check with relevant teams internally on standard operating procedures for starting new projects, especially if those projects involve handling sensitive data.

Work with your Legal and Compliance team

:::callout{theme="success" title="Best practice"} Work with internal legal and compliance teams to determine the documentation necessary for a system to start handling sensitive data. :::

In case of ad-hoc questions or a need for broader alignment, ensure that you as a data administrator or user are in touch with the relevant legal and compliance team to stay informed about needs.

:::callout{theme="success" title="Best practice"} Engage legal and compliance teams early to inform them on the use and scope of the Foundry platform. :::

Connect with Palantir’s Privacy and Civil Liberties Team

Palantir also has a Privacy and Civil Liberties (PCL) team that can be used as a resource for general best practices of handling sensitive data in Palantir Foundry. Contact your Palantir representative to be connected with Palantir's PCL team.

Best practices and tips¶

Ensure data minimization¶

Where sensitive data is not needed for certain user groups or projects, drop the columns or rows containing that data to limit access to sensitive data downstream. Make sure that any access to sensitive data is limited to explicit approved purposes as defined by the data owner(s) and/or relevant data protection and data governance teams.

For an additional layer of security, we recommend using the Cipher service to obfuscate data using cryptographic operations (encryption, decryption, or hashing). Cipher provides users the tools to configure privacy and governance protections in operational workflows on top of Foundry's sophisticated encryption at the storage and network levels.

Ensure accountable data usage¶

Checkpoints is a Foundry application that facilitates accountability and purpose limits by enabling data governance teams to request justifications before certain sensitive data actions can be performed. For more details, see the Checkpoints documentation and workflow for requesting justifications for sensitive actions.

:::callout{theme="success" title="Best practice"} Deploy Checkpoints if users should provide a justification and/or acknowledgment prior to being able to perform actions considered sensitive in your particular processing environment. :::

Scan for sensitive datasets¶

Sensitive Data Scanner is a Foundry application that enables administrators to create organization-specific definitions of sensitive data (such as PII) and a policy around what should happen when data matching this definition is identified. Sensitive Data Scanner can be triggered manually or configured to run in the background and watch for new data entering a dataset, project, or the platform. When Sensitive Data Scanner detects that a dataset contains information that corresponds to a pre-specified definition of sensitive data, the application will trigger a configured response, such as alerting administrators by creating a Foundry-generated Issue or proactively locking down the dataset by applying a Security Marking. For more details, see the Sensitive Data Scanner documentation.

Configure data retention and deletion¶

Data retention describes the process that governs how long data is stored in Foundry and how data is removed from Foundry. Consistent with FIPPs, sensitive data like PII typically need to be deleted as soon as the processing purpose has been fulfilled, in order to comply with applicable data protection regulations.

Depending on your contractual agreements or compliance needs, some data may also need to be retained. You should therefore be mindful that deletion from Foundry at some point becomes irreversible and proactively implement relevant controls, such as eligibility reviews, throughout the retention process.

We highly recommended you determine retention requirements as early as possible, ideally before any data is ingested at all.

For more information, refer to the documentation on how retention works in Foundry, or contact your Palantir representative.

中文翻译¶

数据保护与治理¶

Foundry 使企业用户能够集成、转换、分析和运营企业数据，同时安全地协作和共享数据产品。每项数据战略和计划的重要组成部分是确保数据使用的合法性、正当性、合规性和适当性。数据保护和数据治理是使用 Foundry 的核心概念。

数据保护(Data protection) 指可用的技术和组织手段范围，确保个人数据的处理始终限于实现合法处理结果所必需且相称的范围。
数据治理(Data governance) 指从数据摄取到访问再到删除的整个处理生命周期中对企业数据的管理。

虽然全球各地的隐私法规各不相同，但大多数法规要求采用系统化和程序化的方式来了解组织拥有哪些数据，以便适当使用和处理数据。在 Foundry 中，数据保护和数据治理相辅相成。本文档概述了可供客户使用的最佳实践和工具，以帮助在 Palantir Foundry 中处理数据（包括敏感数据或个人数据）时，实现充分且适当的数据保护和数据治理。

本文档面向数据管理员、数据治理负责人、数据所有者以及在平台上处理敏感数据并希望了解 Foundry 保护这些数据能力的用户。

如果您对数据保护、数据治理或保护敏感数据有疑问，Palantir 设有隐私与公民自由(PCL)团队 ↗，可提供有关在 Palantir Foundry 中处理敏感数据的指导。请联系您的 Palantir 代表，以便与 Palantir 的 PCL 团队取得联系。

数据保护原则¶

平台管理员和用户应始终负责任地处理企业数据，尤其是个人数据或敏感数据。公平信息实践原则(FIPPs)提供了一套有用的指南，作为处理个人数据并强制执行隐私保护的基本原则。

公平信息实践原则(FIPPs)¶

以下，我们基于经合组织《隐私保护与个人数据跨境流动指南》 ↗概述了 FIPPs：

收集限制原则(Collection Limitation Principle)。 个人数据的收集应有限制，任何此类数据应通过合法和公平的方式获取，并在适当时征得数据主体的知情或同意。
数据质量原则(Data Quality Principle)。 个人数据应与其使用目的相关，并在这些目的所需的范围内保持准确、完整和最新。
目的明确原则(Purpose Specification Principle)。 收集个人数据的目的应不迟于数据收集时明确，后续使用应限于实现这些目的或与这些目的不相冲突且每次目的变更时明确的其他目的。
使用限制原则(Use Limitation Principle)。 除以下情况外，个人数据不得为指定目的之外的目的披露、提供或以其他方式使用：a) 经数据主体同意，或 b) 根据法律授权。
安全保障原则(Security Safeguards Principle)。 个人数据应受到合理的安全保障措施保护，以防数据丢失或未经授权的访问、破坏、使用、修改或披露等风险。
公开原则(Openness Principle)。 应制定关于个人数据发展、实践和政策的总体公开政策。应提供便捷的方式来确定个人数据的存在和性质、其主要使用目的，以及数据控制者的身份和惯常居住地。
个人参与原则(Individual Participation Principle)。 个人应有权：
从数据控制者或其他方面确认数据控制者是否持有与其相关的数据；
在合理时间内，以合理的方式和易于理解的形式，获取与其相关的数据，费用（如有）不得过高；
在根据(a)和(b)项提出的请求被拒绝时获知理由，并能够对此类拒绝提出质疑；以及
对与其相关的数据提出质疑，如果质疑成功，有权要求删除、更正、完善或修改该数据；
问责原则(Accountability Principle)。 数据控制者应负责遵守落实上述原则的措施。

这些 FIPPs 的共同主题之一是数据最小化(Data Minimization) 的需求，即数据仅应为明确和授权的目的("目的明确原则")进行收集("收集限制原则")和使用("使用限制原则")。此外，在处理数据时必须始终考虑安全保障("安全保障原则")。

FIPPs 示例¶

例如，考虑以下场景。

一家金融机构(FI)在考虑如何处理提供银行服务所需的新客户计划时，可以应用 FIPPs。

当该金融机构设立该计划时，它只会寻求从注册该计划的客户那里收集运营该计划所必需的个人信息("收集限制原则")，所有目的都事先明确说明("目的明确原则")，并且数据处理的方式和细节公开披露("公开原则")。

当数据准备给用户使用时，数据所有者和数据准备者确保数据定期维护和审查，以便任何与数据相关的决策都使用准确的最新信息("数据质量原则")，并确保所有数据安全存储("安全保障原则")。系统范围的流程（如定期审计审查）确保数据仅用于预先指定的目的("问责原则")。数据准备好供用户使用后，只有经授权的用户才能为批准的目的访问该数据("使用限制原则")。

同时，在消费者方面，该金融机构允许消费者定期请求访问、删除或更正信息("个人参与原则")。此外，除了 FIPPs 之外，可能还需要遵守其他金融部门关于数据为合规目的需要保留多长时间的要求。

仅此示例就涉及处理数据的许多复杂性和考量。本文档中概述的最佳实践将概述 Palantir Foundry 中广泛的技术工具，这些工具有助于在处理敏感数据（包括个人数据）时落实这些基本原则。

超越 FIPPs¶

FIPPs 只是评估个人或敏感信息隐私的起点。公平、非歧视和道德原则也可能与个人数据处理相关。不同的法律、法规和行政要求可能因司法管辖区、部门和一般规范而异。请咨询法律顾问或隐私专家，以获取有关相关要求的建议。

敏感数据分类¶

识别敏感数据是至关重要的第一步。上下文很重要，因为某些数据是否被视为敏感取决于相关的隐私法规和规范。

此处的敏感数据(Sensitive data) 定义为任何被广泛分类和/或需要额外安全性的数据。一些法律正式将特定数据元素指定为敏感数据（例如，欧盟的《通用数据保护条例》），而其他数据则由数据所有者确定或根据普遍认可（无论法律地位如何，例如社会安全号码）来确定。数据是否被归类为敏感数据通常主要取决于数据的类型或分类（例如，个人身份信息）、工作流的类型（例如，限于特定目的）或任何可能触发受限访问控制的内容（例如，敏感的企业信息）。

敏感数据的一个常见示例是个人身份信息(PII)，其中包括直接标识符以及可用于重新识别个人或将其单独识别出来的关于个人的其他信息。

敏感信息的示例包括：

联系信息： 姓名、电子邮件、电话号码
身份证号码： 社会安全号码(SSN)、驾照号码、病历号码、税务识别号码(TIN)
生物识别信息： 面部特征、指纹、个人图像、DNA
日期： 出生日期、入院或出院日期
位置信息： 家庭住址、办公地址、可穿戴设备位置数据、手机位置
健康信息： 过去、现在或未来的身体或心理健康状况、药物、治疗和诊断
财务信息： 收入或资产、医疗账单或付款、账号
其他敏感信息： 通话记录、IP 地址

根据司法管辖区或领域的不同，敏感数据的分类可能有所不同。以下是一些相关数据保护和隐私法规定义的示例：

欧盟《通用数据保护条例》(GDPR) 是一项明确定义个人数据的法规。概括而言，GDPR 将个人数据定义为任何可以识别个人的数据，并将种族和政治观点等特征归类为敏感数据。正式定义如下：

GDPR 第 4(1) 条 ↗ 将个人数据分类为：

与已识别或可识别的自然人（"数据主体"）相关的任何信息；可识别的自然人是指可以直接或间接识别的自然人，特别是通过参考诸如姓名、识别号码、位置数据、在线标识符或与该自然人的身体、生理、遗传、心理、经济、文化或社会身份相关的一个或多个特定因素。

此外，GDPR 第 9(1) 条 ↗ 强调以下类型的个人数据属于需要额外关注和保护的特殊类别个人数据：

揭示种族或民族血统、政治观点、宗教或哲学信仰或工会会员身份的个人数据，以及为唯一识别自然人而处理的基因数据、生物识别数据、有关健康的数据或有关自然人性生活的数据。

美国《健康保险可携性和责任法案》(HIPAA)¶

美国卫生与公众服务部(HHS)的详细指南 ↗中概述的美国《健康保险可携性和责任法案》(HIPAA) 是美国处理医疗保健数据的通用框架。HIPAA 适用于医疗保健提供者和保险公司持有的数据，但不一定适用于同一数据的其他处理者。为确认，请咨询法律顾问或隐私专家以获取有关相关要求的建议。

根据 HIPAA，

受保护健康信息是包括人口统计信息在内的信息，涉及：

个人过去、现在或未来的身体或心理健康状况，

向个人提供的医疗保健服务，或

向个人提供医疗保健服务的过去、现在或未来的付款，并且该信息可识别个人或有合理依据相信可用于识别个人。受保护健康信息包括许多常见标识符（例如，姓名、地址、出生日期、社会安全号码），当这些标识符可以与上述健康信息相关联时。

例如，由 HIPAA 涵盖实体处理的病历、实验室报告或医院账单将是 PHI，因为每个文档都包含患者的姓名和/或与健康数据内容相关的其他识别信息。

其他¶

可能适用于您的组织或项目的其他相关国际数据保护框架包括：

巴西 - 《通用数据保护法》(LGPD)
日本 - 《个人信息保护法》(AAPI)
加拿大 - 《个人信息保护和电子文档法案》(PIPEDA)
美国加利福尼亚州 - 《加州消费者隐私法案》(CCPA) / 《加州隐私权法案》(CPRA)
美国弗吉尼亚州 - 《弗吉尼亚消费者数据保护法案》(CDPA)
美国科罗拉多州 - 《科罗拉多州隐私法案》(CPA)

以上列表并不详尽，明确定义将因当地司法管辖区、地区或部门而异。请咨询您的法律、合规和/或数据保护团队，以了解相关的数据分类以及基于适用规则和法规的具体处理说明。

数据治理监督¶

在开始在 Palantir Foundry 中处理数据之前，请确保您确定了组织中负责数据保护和数据治理的相关主题专家(SME)和问责机构。处理企业数据（包括个人数据和其他敏感数据）会带来一系列考量：从法律和法规要求到将平台/数据所有者设定的组织规则付诸实施。

以下是在开始在 Palantir Foundry 中处理数据之前，需要遵循或与您的组织核实的一系列常见程序：

确定治理委员会/主题专家或指定数据治理负责人

治理委员会不必是一个正式的组织，对于每个组织可能采取不同的形式。重要的是要了解组织中的哪个或哪些负责方负责思考、裁决和帮助解决随着平台使用、用例扩展等出现的数据治理和数据保护问题。
确保数据得到适当处理的责任通常在于各自的数据所有者。这包括确定下文概述的基本数据处理原则应如何应用于特定工作流，以及确保能够满足系统范围的数据治理要求，例如通过审计日志确保平台的可问责使用，以及配置相关的保留策略。
这些数据治理要求通常由组织的数据保护办公室(DPO)、信息安全、合规或法律职能部门定义。

:::callout{theme="success" title="最佳实践"} 咨询相应的数据所有者或数据控制者，以确定了解并能够批准如何根据适用法规、使用协议和其他要求处理数据的相关方。 :::

完成所需的隐私审查或隐私影响评估

根据行业、地区/司法管辖区、应用程序或组织特定要求，在开始处理之前可能需要额外的文档。这可能以组织特定或法规要求的形式出现，需要准备诸如隐私阈值评估、隐私/数据保护影响评估、合规性评估、隐私声明、处理活动记录、系统记录通知(SORN)等文档。
与内部相关团队核实启动新项目的标准操作程序，特别是如果这些项目涉及处理敏感数据。

与您的法律和合规团队合作

:::callout{theme="success" title="最佳实践"} 与内部法律和合规团队合作，确定系统开始处理敏感数据所需的文档。 :::

如果出现临时问题或需要更广泛的协调，请确保您作为数据管理员或用户与相关的法律和合规团队保持联系，以了解需求。

:::callout{theme="success" title="最佳实践"} 尽早让法律和合规团队参与进来，告知他们 Foundry 平台的使用和范围。 :::

联系 Palantir 的隐私与公民自由团队

Palantir 还设有隐私与公民自由(PCL)团队，可作为在 Palantir Foundry 中处理敏感数据的一般最佳实践资源。请联系您的 Palantir 代表，以便与 Palantir 的 PCL 团队取得联系。

最佳实践与技巧¶

确保数据最小化¶

如果某些用户组或项目不需要敏感数据，请删除包含这些数据的列或行，以限制对下游敏感数据的访问。确保对敏感数据的任何访问都限于数据所有者和/或相关数据保护和数据治理团队定义的明确批准目的。

为了增加一层安全性，我们建议使用 Cipher 服务通过加密操作（加密、解密或哈希处理）来混淆数据。Cipher 为用户提供了在 Foundry 存储和网络级别的复杂加密基础上，在操作工作流中配置隐私和治理保护的工具。

确保可问责的数据使用¶

Checkpoints 是一个 Foundry 应用程序，它通过使数据治理团队能够在执行某些敏感数据操作之前请求理由说明，来促进问责制和目的限制。有关更多详细信息，请参阅 Checkpoints 文档和为敏感操作请求理由说明的工作流。

:::callout{theme="success" title="最佳实践"} 如果用户需要在执行特定处理环境中被视为敏感的操作之前提供理由说明和/或确认，请部署 Checkpoints。 :::

扫描敏感数据集¶

敏感数据扫描器(Sensitive Data Scanner)是一个 Foundry 应用程序，使管理员能够创建组织特定的敏感数据定义（例如 PII），以及关于在识别出匹配此定义的数据时应采取何种策略的规则。敏感数据扫描器可以手动触发，也可以配置为在后台运行并监视进入数据集、项目或平台的新数据。当敏感数据扫描器检测到数据集包含与预先指定的敏感数据定义相对应的信息时，该应用程序将触发配置的响应，例如通过创建 Foundry 生成的问题(Issue) 来提醒管理员，或通过应用安全标记(Marking)来主动锁定数据集。有关更多详细信息，请参阅敏感数据扫描器文档。

配置数据保留和删除¶

数据保留(Data retention) 描述了管理数据在 Foundry 中存储多长时间以及如何从 Foundry 中删除数据的过程。与 FIPPs 一致，敏感数据（如 PII）通常需要在处理目的完成后立即删除，以遵守适用的数据保护法规。

根据您的合同协议或合规需求，某些数据可能也需要保留。因此，您应注意，从 Foundry 中删除数据在某个时间点将变得不可逆，并应在整个保留过程中主动实施相关控制措施，例如资格审核。

我们强烈建议您尽早确定保留要求，理想情况下是在任何数据被摄取之前。

有关更多信息，请参阅关于 Foundry 中保留机制如何工作的文档，或联系您的 Palantir 代表。