Data and trust
Understand the terms before you share the data.
A data project should make clear what is accessed, excluded, received, and permitted. Those questions belong in a project agreement, not an assumption based on a public form.
Define sources and exclusions.
A project should specify systems, record types, time periods, and fields in scope. Sensitive information and sources that cannot be licensed for the intended use can be excluded. Initial assessment forms ask for descriptions, not customer files or credentials.
Match permissions to the intended use.
Access, preparation, buyer evaluation, model training, and onward licensing are different permissions. The project must establish rights for its specific use.
Reduce risk, then review what remains.
A plan may include removal of direct identifiers, transformations of identifying details, restricted access, or purpose-built scenarios. Indirect clues and linked records can still identify people or businesses. De-identification reduces risk; it does not eliminate it.
Put handling and retention in writing.
Before source access, a project should define extraction method, storage location, access roles, subprocessors, retention periods, and deletion process. Ending future sharing does not necessarily revoke rights already granted, and deletion cannot be assumed to remove a dataset’s influence from a trained model.
This page describes questions for a proposed engagement. It does not represent a security certification or a completed handling program.