You Have 72 Hours to Tell People You Got Hacked

Ask a founder if they have a security plan and most will point to something: two factor auth, encrypted backups, maybe a password manager the whole team actually uses. Ask them what happens the day someone finds a database dump of your customers' emails on a forum, and you mostly get silence.

That silence is the expensive part. Not the breach itself, the seven days after it, when you're supposed to know who was affected, what was in the data, who to tell, and how fast the law says you have to tell them.

The clock starts before you're ready

Depending on where your customers live, you may already be on a legal timer the moment you confirm a breach. Several privacy regimes, including PIPEDA in Canada and GDPR in the EU, expect notification to a regulator within a short fixed window once you know personal data was exposed, sometimes as tight as 72 hours. Miss that window because you spent three days arguing internally about whether it was "really" a breach, and you've turned a security incident into a compliance failure too.

Most small teams don't miss the window because they're careless. They miss it because nobody ever wrote down who makes the call, who drafts the notice, and who has the authority to hit send. In the moment, with a half built picture of what actually leaked, that ambiguity is paralyzing.

What a real plan actually needs

You don't need a binder. You need answers to four questions, written down somewhere the team can find at 2am:

• Who declares an incident, and who do they wake up first
• Where the list of what data you actually store lives, so you can scope the damage fast
• A notification template you can fill in and send within hours, not draft from scratch under pressure
• Who talks to customers, and who talks to press or regulators, so those aren't the same rushed person

That last one matters more than it sounds. A vague, defensive notice erodes trust faster than the breach did. A clear one, sent early, with a real explanation and a real fix, is the difference between customers who stay annoyed for a week and customers who leave for good.

The part that actually prevents this

None of this replaces good engineering: least-privilege access, encrypted data at rest, logging you can actually query when something looks wrong. But plenty of teams have decent security hygiene and zero incident process, and that's the gap that turns a contained problem into a public one. The plan is cheap. Building it after the fact, under a deadline, with lawyers on the phone, is not.

If your product handles customer data and nobody could tell you today what your notification obligations are, that's worth fixing before you need the answer. We help teams build software with this baked in from the start rather than bolted on after an incident, and if you want a second set of eyes on where the gaps are, a free MVP build is a low-risk way to see how we approach it. Otherwise, get in touch and we'll talk through what your specific setup actually needs.