DawnOps

SOC2 for Builders, Part 2: Data Classification and Logging Hygiene

If you only do one SOC2 thing, stop logging raw payloads. It’s the fastest way to create avoidable risk and the easiest place to tighten up.

This is how we keep data classification and logging hygiene simple enough to stick.

SOC2 for Builders series

Three buckets are enough to start

We use three classifications and only expand if we truly need to:

  • PII: identity data like names, emails, phone numbers.
  • Customer content: user-provided text, files, or internal data.
  • Safe: metadata that’s safe to log (ids, timestamps, status).

Once you can label a field, you can decide what never shows up in logs.

Tag data at the source

The safest place to classify data is where it enters the system. We tag fields in schemas and database models and enforce that every field has a classification. If a field is missing a tag, CI fails.

That makes privacy hygiene a build error, not a vague policy.

Logging rules we actually follow

  • Don’t log raw payloads.
  • Log stable ids, not user-provided strings.
  • Prefer event names over blobs.
  • Redact by default when in doubt.

A good event log looks like this:

{
  "event": "demo_request.created",
  "request_id": "req_123",
  "lead_id": "lead_456",
  "outcome": "accepted"
}

This is enough to debug without storing sensitive inputs.

Clean up existing logs in small passes

If you already have noisy logs, fix them in slices:

  • Remove raw inputs from the most common events first.
  • Add redaction helpers in one place.
  • Backfill a safe event schema and migrate over time.

Next up

Part 3 covers access control and least privilege. It’s the other half of keeping sensitive data safe without slowing teams down.

References

Keep going