Estateeze

Security policy

Estateeze holds highly sensitive client data — Life Files, Wills, Trust deeds, RSA ID numbers, financial records. If you've found something that could compromise that data, this page is the front door.

Reporting a vulnerability

Please report suspected security issues privately. Do not open a public GitHub issue for anything with security implications.

Primary channel

Email security@estateeze.co.za.

Backup channel

Message Phia (Platform Support Lead) or Byron (Technical Lead) directly via any professional channel you can find us on — GitHub, LinkedIn, or the general Estateeze support address support@estateeze.app with the subject line prefixed [SECURITY — PRIVATE] so it gets pulled into the private response track instead of the general support queue.

What to include

  • Reproduction steps — the smallest sequence that reliably triggers the issue
  • Affected URL, endpoint, or component — be specific
  • Your severity assessment (Sev-1 / Sev-2 / Sev-3 / Sev-4 — best judgement)
  • Impact — what could an attacker realistically do with this?
  • Proof-of-concept only if safe to demonstrate. Text descriptions and screenshots preferred; no live exploit payloads
  • Suggested mitigation if you have one — welcome but not required

What NOT to do

  • Never run destructive payloads against production data. If you need to demonstrate impact on real data, contact us first and we'll spin up a demo tenant.
  • Never access, download, or retain data belonging to other users beyond the minimum necessary to confirm the vulnerability.
  • Never publicly disclose before we've shipped a fix — see the coordinated-disclosure line in the SLA table.

PGP encryption

We do not currently publish a PGP key. The team is small enough that PGP overhead outweighs its value. If a report is sensitive enough to warrant end-to-end encryption, say so in your first message and we'll set up a Signal thread for the technical detail.

Response SLA

Commitments to reporters. The clock starts from receipt of the first report.

Milestone Sev-1 (critical) Sev-2 (high) Sev-3 (medium)
Acknowledgement 72 hours 72 hours 72 hours
Triage complete 7 days 7 days 7 days
Fix shipped to production 30 days 60 days 90 days
Public disclosure Coordinated Coordinated Coordinated

Coordinated disclosure means we agree with you, in writing, on a public disclosure date. Normally that date is when the fix ships to production, but we're happy to extend to give you time to prepare a write-up. Under no circumstances will we push you to disclose before a fix ships.

Scope

In scope

  • The production application (Estateeze on Heroku and any *.estateeze.co.za custom domain once DNS lands)
  • Any staging or preview deployment we have explicitly granted you access to
  • The Estateeze GitHub repository — code-level review is welcome; if you find something on a main merge, report privately per above rather than as a public issue

Out of scope

  • Third-party services we depend on — Heroku, AWS S3, Sentry, Google Gemini, Mailgun, Cloudflare, GitHub, PayFast. These have their own security response processes; report to them directly.
  • Denial of Service. Please do not stress-test production. We can arrange a staging load test if needed.
  • Automated scanning noise. Findings that only surface via nmap / dirbuster / SQLmap without human-driven analysis + validation are not eligible for coordinated response.
  • Brute-force / credential-stuffing on real accounts. Try this on a demo tenant we provide. Our account lockout (5 attempts / 15-minute sliding window → 30-minute lock) will trigger against test attempts.
  • Social engineering — no phishing our team, no vishing our clients. The humans are out of scope.
  • Physical or physical-adjacent attacks. We don't operate physical offices.

If you're unsure whether something is in scope, ask before testing — we'd rather answer a scoping question than miss a report.

Safe Harbor

Estateeze commits to the following for good-faith security research conducted within the scope defined above:

  1. We will not initiate legal action against you for security research that stays within scope. That includes research that unintentionally accesses a limited amount of data, provided you (a) stop as soon as the vulnerability is confirmed, (b) do not retain or share the accessed data, and (c) report the finding to us promptly.
  2. We will not report you to law enforcement for good-faith in-scope research. If a third party (client firm, regulator, or vendor) initiates action against you for a report you made to us in good faith, we will speak up on your behalf and confirm the research was authorised under this policy.
  3. South African legal context. Activity within the scope defined above is intended to fall within the authorisations contemplated by the Cybercrimes Act 19 of 2020 (Chapter 2 distinguishes authorised access from the enumerated offences) and to remain compatible with POPIA's public-interest research exemption. This is a statement of intent, not legal advice — raise legal concerns with us before testing and we can put something more formal in writing.
  4. What safe harbor does NOT cover: activity outside the scope defined above; retention or exfiltration of data beyond the minimum needed to confirm a vulnerability; public disclosure before an agreed date; social engineering; testing against production accounts belonging to real users; or activity that would trigger a POPIA §22 breach notification by demonstrably harming a data subject.

If you'd like a more formal indemnity letter for a specific engagement, contact us before you start and we'll put one in writing.

POPIA §22 breach notification

Confirmed breaches involving personal information are notified to the Information Regulator and each affected data subject within 72 hours of confirmation, per POPIA §22. If a report you make to us confirms a breach, we take the reporting obligation from that point — you are not asked to notify data subjects directly on our behalf. We may ask you to hold public disclosure for a short additional window while we complete the regulator submission, which is normally same-day.

Recognition

We keep a public hall of fame for researchers who report responsibly — reporter name (or pseudonym, your choice), report date, redacted one-sentence finding description, severity tier, and optional link to your website or social profile. Opt-in only. If you'd rather stay anonymous, the fix ships regardless.

We do not currently offer a monetary bug bounty. If Estateeze grows to a scale where a bounty is defensible, we'll launch one via HackerOne or Bugcrowd and update this page in the same commit.