Data Handling
"How we collect, store, access, and delete client data securely."
Why this exists
Client data isn't ours. We are temporary stewards of it. This distinction means we never use real data for testing without anonymizing it, never retain it longer than needed, and never treat access as a perk.
Operational Flow
Classification: Classify all client data at kickoff into Public, Internal, Confidential, or Restricted. Restricted data includes personal info, financial records, and health data.
Minimum access: Engineers access only the data they need. Production database access requires a specific request, a reason, and a log entry.
No real data in development: Never copy production data into local or staging environments. Generate synthetic data using Faker. If the client demands real data, anonymize it first.
Storage rules: Store Confidential and Restricted data encrypted at rest. Use managed services like RDS or S3 with encryption enabled. Do not write custom encryption.
Retention: Delete data within 30 days of project completion, after confirming with the client what to export or archive.
Transfer: Use secure channels like encrypted email, 1Password links, or SFTP to share sensitive files. Do not use unencrypted Dropbox links.
Breach notification: Notify the client within 24 hours if data is exposed without authorization. Inform them before researching the full scope.
What good looks like
- A developer debugs a data processing issue on staging using a sanitized database copy, with the access logged in Slack.
- The project handoff includes a signed data disposition note confirming what was archived or deleted.
- A senior engineer redirects a junior developer to a Faker seed script instead of letting them clone the production database.
What NOT to do
- Don't use real client email addresses or names in screenshots, demos, or documentation.
- Don't keep client data 'just in case' after a project closes. The liability outweighs any convenience.
- Don't delay breach notifications to gather more facts. A prompt, honest update is always better than a late one.
The phrase ‘we take security seriously’ means nothing. It is a cliché used by companies right after a breach. What we actually do at Kryft is handle other people’s data with strict limits. We classify data at project kickoff so we do not treat Restricted records like public logs. A few minutes of upfront classification prevents major mistakes later.
The hardest rule to follow is avoiding real data in local development. It is inconvenient. Production data has quirks that synthetic data misses, and cloning the database for local debugging is fast. Don’t do it. If you can’t reproduce a bug with synthetic data, work with the client to get a sanitized extract, run it in staging, and log the access. It is not the easiest path, but it is the only one you can defend.