Reference
Define security requirements for each data flow.
Treat public web evidence and customer-provided files as separate data classes. Define access, retention, processing, and delivery controls for each.
Example data-flow review
One example record
- Input
- Customer CSV with company, website, record ID, and owner
- Processing
- Company matching and public website research
- Output
- Updated CSV with supported findings and evidence links
- Access
- Named customer and Kaiju operators involved in the evaluation
Data classes
Classify what moves through the product
Different records require different handling.
- 1
Publicly observable website and network evidence
- 2
Customer-provided company files and identifiers
- 3
CRM fields, ownership context, and other fields from customer systems
- 4
Support, review, and correction communications
Access control
Minimize who can access customer files and results
Start with the narrowest practical access model.
- 1
Small test sets before broader system access
- 2
Only the fields required for the stated use
- 3
Downloaded files before automated writes into another system
- 4Role-based access to customer outputs
Retention
Define retention and deletion
The input and generated output should have an explicit lifecycle.
- 1Uploaded-file retention
- 2Processed-result retention
- 3Logs and error records
- 4Deletion and correction requests
Delivery controls
Review the controls for the delivery path you actually use
CSV, connected CRM and workflow delivery, webhooks, and API access create different credential, permission, and write risks.
- 1
Uploaded files, downloaded CSVs, and where those files are stored after export
- 2
CRM or workflow fields, permissions, and destinations enabled for Growth or Team
- 3
Webhook endpoints, authentication, retry behavior, and ownership when webhooks are enabled
- 4
API credentials, scopes, rotation, and access granted through Team API credentials