Security

How we think about security at Hardal - and the specific practices we follow.

Berkay Demirbas
4 min read

Security isn't a compliance exercise. We handle customer tracking data, first-party identifiers, and in some cases hashed personal information. Our customers trust us with infrastructure that sits between their users and their marketing platforms. We take that seriously.

Core principles

Privacy by default. We don't collect more data than we need. We hash or redact PII before it leaves our infrastructure where possible. When we build new features, we ask: what's the minimum data we need to make this work?

Least privilege. People and systems get access to exactly what they need - no more. This applies to API keys, database access, cloud permissions, and customer data access.

Defense in depth. We don't rely on a single security control. If one layer fails, others should catch it.

Data handling

Customer data stays isolated. Each customer's tracking data is kept separate. We don't use production data for development or testing. We use anonymized or synthetic data for local development.

PII is treated with extra care. IP addresses, email hashes, user identifiers - anything that could identify a person is handled with explicit rules. When we store or transmit PII, we document why, for how long, and with what protections.

Retention policies are set and enforced. We don't keep data indefinitely. Each data type has a defined retention period. These are reviewed when regulations change (GDPR, KVKK, etc.).

Access management

Credentials are never shared in Slack or email. Use 1Password. If you need access to a customer system or a shared credential, it should come through 1Password, not a DM.

Rotate credentials when someone leaves. Any shared password or API key that a departing employee had access to gets rotated on their last day. No exceptions.

MFA on everything important. Google Workspace, cloud providers, GitHub, any admin panel - mandatory MFA. If you're an admin on a customer system, MFA is required.

Review access quarterly. Once per quarter, we check whether everyone still needs the access they have. Stale access is removed.

Infrastructure

No hardcoded secrets. Credentials, API keys, and tokens are environment variables or secrets manager entries - not committed to the repository. GitHub secret scanning is enabled.

Dependency updates are not optional. We keep dependencies current. Security vulnerabilities in npm packages and system libraries get patched promptly. We use automated tooling to flag these.

Cloud permissions are scoped. IAM policies follow least-privilege. We don't use wildcard permissions in production environments.

What to do if you suspect a security issue

  1. Don't panic, don't speculate publicly
  2. Tell Berkay immediately via Slack DM or call
  3. Don't try to fix it yourself unless instructed - you might destroy forensic evidence
  4. Document what you found and when

If a customer's data may have been exposed, we tell them promptly and honestly - even if we're not 100% sure. We don't wait for certainty before disclosing.

Responsible disclosure

If you're a researcher and you've found a security vulnerability in Hardal, please email security@usehardal.com. We'll respond within 48 hours, work with you to understand the issue, and give you credit if you'd like it once it's resolved.

We don't pursue legal action against good-faith security researchers.

GDPR and KVKK

Security and privacy compliance are intertwined. We maintain a data processing register, have DPAs with our subprocessors, and can respond to data subject requests. If a customer asks us a compliance question, we answer it accurately - not evasively.

See the Privacy & Compliance section of our FAQ for the customer-facing version of these commitments.