Privacy and civil liberties principles become meaningful when organizations translate them into decisions, processes, and technical controls throughout a system's lifecycle. Start by defining the purpose of a workflow and the data needed to achieve that purpose. Identify who should have access, which decisions require human review, and when to retain or delete data.
The capabilities on this page can help your organization put its own policies and responsibilities into practice. They do not determine whether a use is lawful, necessary, or proportionate, and they do not guarantee compliance with a law, regulation, or policy. Work with your organization's data owners, privacy, legal, compliance, security, and governance teams to choose and maintain appropriate controls.
Proportionality asks whether a workflow's data use and effects are appropriate for its legitimate purpose. Minimization narrows collection, access, use, and retention to what that purpose requires. Consider these principles before ingesting data and revisit them when a workflow or purpose changes.
Use Sensitive Data Scanner to help identify data that matches organization-specific definitions of sensitivity. Use markings and project roles to limit access according to centrally managed eligibility criteria and project responsibilities. Where a workflow does not require direct identifiers, use Cipher to apply privacy-enhancing cryptographic transformations such as hashing or encryption.
These controls support minimization only when their configuration reflects a considered decision about which data and access are necessary. Detection, restriction, or obfuscation does not replace that decision.
A manufacturing team builds a Pipeline Builder workflow to predict when equipment needs maintenance. The source records include machine telemetry, work-order notes, and technician contact details. The team uses Sensitive Data Scanner to identify sensitive fields and removes contact details because they do not support the prediction workflow. It configures a match action to apply a marking to the raw dataset. If the workflow needs to recognize repeat service patterns, the team uses Cipher to hash technician identifiers into consistent values.
Applying proportionality and minimization early helps the team determine which fields are necessary before sensitive data propagates into models, applications, and downstream datasets. Without this analysis and the supporting controls, technician contact details could be copied into downstream assets even though they do not improve the prediction workflow. The resulting workflow preserves useful maintenance signals while reducing unnecessary collection and access.
Purpose limitation connects the collection, access, and use of data to specific, legitimate purposes. Define permitted purposes before granting access, and reassess permissions when a purpose ends or changes.
Checkpoints can ask users to provide a justification before sensitive interactions and retain the resulting records for review. Approvals can route requested changes or access through designated reviewers. Markings and project permissions can then enforce the access boundaries that your organization establishes. Together, these capabilities can connect policy, justification, review, and access without assuming that every approved request is appropriate for every purpose.
An operations team creates a Data Connection export that sends supplier delivery records to a planning system. The team limits the export to the fields needed to forecast deliveries and uses project permissions to restrict who can configure it. The team routes requests for access to the export project through Approvals. If users export detailed supplier objects from a Workshop planning application, a checkpoint can ask them to record the shipment or planning task that requires the export.
Applying purpose limitation helps the team define the permitted purpose before data is shared and identify when a new recipient, field, or use requires another review. Without these boundaries, later changes could add unrelated fields or recipients to an established export without renewed scrutiny. An approval records a decision at a point in time; it does not authorize unrelated future uses.
Access governance should reflect both eligibility to handle a type of data and the role a person has in a particular workflow. Apply least-privilege access, use groups where possible, and review access as responsibilities change.
Markings provide mandatory controls that remain with protected resources and derived data, while project roles and permissions govern access within a project. Approvals can place human review in access-request workflows. Compass helps users organize resources into projects, understand where resources live, and request access through governed workflows.
No single permission model defines an organization's policy. Data owners and administrators must decide which combinations of mandatory controls, roles, groups, project boundaries, and review processes are appropriate.
A facilities team builds a Workshop application that combines building-capacity data with vendor contracts. Most users need site-level totals, while a smaller contract team needs detailed commercial terms. The team applies markings to contract resources, uses project roles to separate application builders from viewers, and documents ownership in Compass. Approvals provides a review point when someone requests exceptional access.
Separating eligibility from workflow-specific need helps the team determine who should have access to contract data. Without separate controls on the underlying resources, access to the facilities application could expose detailed contract terms to every viewer. The controls prevent broad application access from becoming broad access to every underlying resource.
Privacy-enhancing transformations can reduce exposure by replacing direct identifiers or limiting when original values are available. Choose a technique based on the workflow's purpose, the risk of re-identification, and whether authorized reversal is necessary.
Cipher supports hashing, encryption, and controlled decryption in operational workflows. Combine these transformations with access controls and governance processes so that permissions to transform or reveal data correspond to defined responsibilities and purposes. Transforming a value does not automatically make data anonymous or remove privacy risk.
A support team builds a Pipeline Builder pipeline to analyze recurring issues across service records. Analysts need to group records associated with the same account, but they do not need direct account identifiers. The pipeline uses Cipher to replace each identifier with a consistent hashed value, while the original records remain in a restricted project for authorized follow-up.
Considering privacy-enhancing transformations early helps the team decide whether a stable identifier is necessary and evaluate whether other fields could still reveal an identity. Without the transformation, direct account identifiers could spread into derived analyses and exports used by people who do not need them. Obfuscation reduces exposure, but the team must continue to govern access to the transformed dataset and any process that can reconnect it to the source.
Human agency and oversight help ensure that consequential actions remain reviewable and that designated decision-makers can question, approve, reject, or change a proposed course of action. Identify where human judgment is necessary and give reviewers enough context to make meaningful decisions.
Approvals routes changes to eligible reviewers before they are applied. Checkpoints can interrupt sensitive interactions to request a justification or acknowledgment. Configure these capabilities around substantive review criteria and clear accountability, rather than treating approval or acknowledgment as a procedural formality.
An AIP Logic function analyzes equipment telemetry and service records, then proposes an action that changes a maintenance schedule represented in the Ontology. Automate runs the function when equipment conditions change and stages the action as a proposal for human review. A maintenance planner can inspect the supporting information and Agent decision log before accepting or rejecting the proposal. If a planner instead submits a manual schedule-change action from a Workshop application, a checkpoint can ask them to record their reason.
Applying human agency and oversight principles helps the team identify which actions require human judgment and what context a reviewer needs. Without review before the action is applied, an incorrect or poorly supported proposal could automatically alter maintenance work and disrupt operations. Human review is meaningful only when a reviewer has sufficient information, authority, and time to change the outcome.
Accountability requires organizations to define who is responsible for a workflow and to maintain records that support review, investigation, and improvement. Document governance decisions, monitor whether controls operate as intended, and establish processes for responding to issues.
Audit logs provide records of actions across Foundry that users can monitor and analyze. Submitted checkpoints create records of users' justifications, and completed requests in Approvals preserve decisions about proposed changes. Compass provides a legible project and resource structure that can help teams understand ownership and manage governed resources.
Records alone do not create accountability. Organizations must determine which events to review, who performs that review, how often it occurs, and what happens when activity conflicts with policy.
An organization uses a Workshop application to review contracts and submit contract-status actions. Compass identifies the project owner, submitted checkpoints create records of justifications for contract exports and action submissions, and audit logs capture activity such as permission changes and object exports. The governance team reviews relevant events on a defined schedule and investigates activity that does not match the project's stated purpose.
Applying accountability principles helps the organization choose which events are meaningful, who should examine them, and how findings lead to action. Without defined ownership and review, inappropriate permission changes or exports could go unnoticed even though Foundry recorded them. This approach also helps avoid collecting or retaining more monitoring data than the accountability process requires.
Retention and deletion policies should reflect the purposes for which data is held, applicable obligations, and the effects of deletion throughout a data system. Define these requirements early, review them when purposes change, and account for derived copies.
Data Lifetime allows organizations to configure lineage-aware retention policies for datasets and their derived data. Compass supports resource management workflows, including moving resources to trash and managing projects. Use these capabilities as part of a broader retention process that assigns policy ownership, validates scope, preserves required records, and confirms outcomes.
A team creates a Compass project and a Pipeline Builder workflow that combine equipment diagnostics, service records, and derived analysis for a time-limited warranty investigation. Before work begins, the data owner defines how long to retain the raw and derived data and separates records that require a different retention period. Data Lifetime applies the selected deletion policy through dataset lineage, Compass identifies the project owner, and audit logs support review of policy changes.
Planning for retention and deletion early helps the team avoid indefinite retention as the default and account for downstream copies before the project ends. Without a lineage-aware policy, temporary raw data and derived datasets could remain available long after the investigation closes. The team still needs a process to confirm policy coverage, deletion outcomes, and preservation of necessary records.
For more detailed guidance about sensitive data and governance responsibilities, review data protection and governance.