Website or SaaS Hacked? What to Do in the First 24 Hours

If you're reading this because it's happening right now: breathe. The next steps matter more than the panic. This is a chronological guide — the first minutes, the first hours, the first 24 hours — for anyone discovering that their company's platform has been (or is being) attacked.

If you're reading this before any incident: even better. Save this link somewhere easy to reach (your company Notion, a shared Google Drive, a GitHub README). On the day you need it, you won't have the headspace to go looking.

First things first: have you actually been hacked?

Common symptoms that usually point to a real attack:

• Site content changed on its own (strange messages, defacement)
• Customers complaining about emails you never sent
• Charges on the company card that nobody made
• A ransom demand by email (ransomware)
• Your bank flagging suspicious activity on a company account
• Your hosting provider (Vercel, AWS, Hostinger) warning about abnormal resource usage
• A server that's extremely slow for no obvious reason
• Strange log entries nobody on the team can explain

Symptoms that could be something else:

• Site down (usually DNS, hosting or a bug — not every outage is a hacker)
• An isolated 500 error (usually a bad deploy)
• A customer reporting they saw the wrong data (could be a bug)

Important: even if you're not sure, treat the first steps as if it were a real attack. The cost of handling an incident that doesn't exist = small. The cost of ignoring a real incident for hours = huge.

🚨 The first 15 minutes — don't make it worse

What NOT to do (important)

• Don't shut down the server. You'll wipe out traces and make the investigation harder. Containing is not the same as shutting down.
• Don't delete suspicious files. They're evidence. You'll need them to understand how the attackers got in.
• Don't change passwords from the compromised panel. If the attacker still has access, they'll see the new password. Change them through independent channels (covered in step 5).
• Don't talk to customers or the press before you understand the scope. Getting the message wrong early leads to lawsuits, unnecessary panic and lost credibility.
• Don't pay the ransom (ransomware). Paying doesn't guarantee recovery — reports from Sophos and Veeam show that roughly 1 in 3 organizations that pay can't recover all their data. And paying marks your company as a soft target: victims who pay are often hit again in the months that follow.
• Don't try to “fix the bug” before you understand what happened. You may be closing door 1 while the attacker walks in through door 2.

What to do now (in order)

Step 1 — Mobilize an organized response (5 min)

Over a secure channel (Signal or WhatsApp on personal phones — NOT company email), alert the 3 to 5 key people:

• Founder/CEO
• Technical lead (CTO or senior developer)
• Head of finance
• Legal (in-house or outside counsel)
• Data Protection Officer (DPO), if you have one

Spin up a virtual war room (Discord, a private Slack channel or a conference call). Name ONE person as coordinator — without a coordinator, everyone does everything wrong in parallel.

Step 2 — Document everything (5 min, in parallel)

Create a Google Doc or Notion page with timestamps. From now on, write down:

• When you noticed (exact date and time, with time zone)
• How you noticed (a customer, a log, an automated alert)
• Exactly what you saw (screenshots, copied messages)
• Every decision made, and by whom

This document is worth its weight in gold for: notifying the data protection authority (in Brazil, the ANPD, which enforces the country's General Data Protection Law, the LGPD), the follow-up investigation, your defense in court and your report to customers. Without a documented timeline, the post-incident phase turns into a nightmare of conflicting versions.

Step 3 — Contain (don't shut down) — 15 min

“Containing” means cutting off the attacker's access without destroying their tracks. In order:

• Cloudflare: turn on “Under Attack Mode” (Security → Under Attack Mode). It adds a JS challenge to every request, making automated attacks harder.
• Block suspicious IPs you've identified in the logs (Cloudflare → Security → Tools → IP Access Rules).
• Temporarily disable admin panels (make the /admin route return a 503 manually).
• Revoke issued API tokens (Stripe, OpenAI, Resend, etc. — every key needs to be rotated).
• Don't delete logs or suspicious files. Copy them off the server, but keep the originals.

Step 4 — Snapshot everything (30 min)

Before making any more changes, take a digital snapshot of the current state:

• Server snapshot (AWS, Google Cloud, current Vercel deployment hash)
• Database backup to a separate S3 bucket or Drive
• Copy of your hosting logs (last 30 days if possible)
• Copy of your Cloudflare logs (last 7 days)
• Git commit history (any rebases or force-pushes?)
• Current list of users with admin permissions

These files will be critical for the investigation. Without them, you won't find out how the attackers got in, and you'll remain open to a repeat attack.

Step 5 — Rotate credentials (1h)

In order of priority:

1. Main company email (usually the “master key” — whoever controls email can reset the password on everything)
2. Hosting dashboard (Vercel, AWS, Hostinger)
3. Cloudflare dashboard
4. Domain registrar account (GoDaddy, Namecheap, Registro.br for .br domains)
5. Banking and finance (lock them down immediately)
6. Stripe / PayPal / Mercado Pago
7. GitHub / GitLab / Bitbucket
8. Critical SaaS tools (Slack, Discord, Notion, Google Workspace)
9. Database (rotate the admin user's password)
10. Integration tokens (OpenAI, OAuth secrets, JWT signing keys)

Important: new passwords must come from a password manager (1Password, Bitwarden), and every critical account should have 2FA through an authenticator app (Authy, Google Authenticator), not SMS (SMS is vulnerable to SIM swapping).

Step 6 — Assess the exposed data (2–4h)

The critical question: what did the attacker get access to?

Sort it into categories:

• Customer personal data (national ID numbers, email, phone, address, bank details) — triggers data protection obligations (the LGPD in Brazil, the GDPR in the EU)
• Financial data (transactions, balances, card data) — triggers PCI DSS and, in Brazil, Central Bank (BACEN) rules
• Sensitive data (health, legal, education) — triggers the LGPD, with heavier fines
• Customer credentials (hashed passwords, tokens) — maximum alert
• Proprietary content (source code, internal documents)
• Public data (already accessible) — low severity

If personal data was accessed, the notification clock is ticking — notify the data protection authority within the deadline set by the applicable law (72 hours under the GDPR). In Brazil, LGPD Art. 48 requires you to notify the ANPD and the affected data subjects within a reasonable time when the incident may cause “relevant risk or harm.” The law itself sets no fixed deadline, but the ANPD's incident reporting regulation (Resolution CD/ANPD No. 15/2024) sets it at 3 business days.

Step 7 — Notify the required parties (4–24h)

Data protection authority (if personal data was exposed)

Notify the authority under the applicable law. In Brazil, that's the ANPD — official form at gov.br/anpd. You'll need to report:

• The nature of the affected data
• The approximate number of data subjects
• The likely risks
• The measures taken
• The timeline for notifying data subjects

Affected customers

A direct notice, in plain language, covering:

• What happened, in 2 sentences
• What data may have been exposed
• What you're doing about it
• What the customer should do (change their password, turn on 2FA, monitor their account)
• A direct channel for questions

Don't lie, don't downplay, don't use jargon. Customers who find out you hid information sue.

BACEN (if you're a financial institution in Brazil)

Brazil's financial cybersecurity rules — BACEN Resolution 4,893 (CMN 4,893) and BCB Resolution 85 — require immediate reporting of cyber incidents at financial and payment institutions authorized by the Central Bank of Brazil (BACEN). Tight deadlines, heavy fines for delays.

Step 8 — Technical investigation (24–72h)

This is usually where a specialized firm comes in (forensics + pentest). The goal is to answer with certainty:

• How the attacker got in
• How long they were inside
• What they did
• Whether they still have any access
• Whether other exploitable vulnerabilities exist (to close them before bringing the system back up)

Without this investigation, you may fix the symptom and leave the cause untouched. The attacker comes back 30 days later through a different door.

Step 9 — Remediation + a safe return (3–14 days)

Before bringing the system back up:

• The exploited vulnerability must be fixed
• Any other serious vulnerabilities identified must be fixed
• All compromised credentials must be rotated
• Backups must be validated (having them isn't enough — you have to test a restore)
• Additional monitoring must be in place (alerts for similar patterns)
• A retest must be done by an independent third party

What to expect over the following month

A realistic estimate, based on public incidents in Brazil (figures in Brazilian reais):

Typical total for a mid-sized incident at a Brazilian SaaS: R$ 200,000 to R$ 1,500,000. An annual preventive pentest costs a fraction of that.

The best time to read this was yesterday

If you're reading this in emergency mode, talk to us: No Vuln can run an emergency pentest + forensics and respond within 24 hours. Send a message with “EMERGENCY” in the subject line to [email protected] or reach us on WhatsApp.

If you're reading this preventively: good sign. Book a call and we'll assess what needs hardening before it turns into an emergency.